E2e тестирование что это
End-to-end или E2E-процесс: что это? Сквозное тестирование
и другие поведенческие факторы.
К примеру, компания Гугл при разработке своих продуктов следует правилу «70-20-10», цифры которого показывают процентное соотношение от общего количества тестов, то есть:
70% занимают юнит-тесты;
20% занимают интеграционные тесты;
Нет единого алгоритма сквозного тестирования, так как многое будет зависеть от сложности самого проекта и что конкретно нужно тестировать. Е2Е — это лишь название процесса тестирования, а не его метод или алгоритм. Но при этом выделяют два основных типа сквозного тестирования, на которых мы немного остановимся.
Любой сквозной тест — это:
в первую очередь тестирование UI;
тяжелый и медленный тест;
применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы;
тяжелый «отлов» найденной проблемы;
тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»;
Заключение
нагрузку на каждый трос или балку;
поведение моста при наводнении, землетрясении, пожаре или аварии на нем;
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Знакомство с фронтенд-тестированием. Часть третья. E2E-тестирование
Авторизуйтесь
Знакомство с фронтенд-тестированием. Часть третья. E2E-тестирование
Рассказывает Гил Тайяр, автор блога на Hackernoon
В этой части мы рассмотрим сквозное (E2E) тестирование: протестируем всё приложение целиком, причём сделаем это с точки зрения пользователя, по сути, автоматизируя все его действия.
В нашем случае приложение состоит только из фронтенда — бэкенда попросту нет, поэтому E2E-тестирование будет заключаться в открытии приложения в реальном браузере, выполнении набора вычислений и проверке валидности значения на экране.
Нужно ли проверять все перестановки, как мы делали это в юнит-тестах? Нет, ведь это уже проверено! В E2E-тестах мы проверяем работоспособность не отдельных юнитов, а всей системы сразу.
Сколько нужно E2E-тестов?
Первая причина, по которой таких тестов не должно быть много, — хорошо написанных интеграционных и юнит-тестов должно хватить. E2E-тесты должны проверить, что все элементы корректно связаны между собой.
4–5 декабря, Онлайн, Беcплатно
Вторая причина — они медленные. Если их будет сотня, как юнит-тестов и интеграционных, то тестирование будет проходить очень долго.
Третья причина — непредсказуемое поведение E2E-тестов. О таком явлении есть пост в блоге Google, посвященном тестированию. В юнит-тестах не наблюдается такого нестабильного поведения. Они могут то проходить, то падать — причем без видимых изменений, исключительно из-за I/O. Можно ли убрать непредсказуемость? Нет, но можно свести её к минимуму.
Чтобы избавиться от непредсказуемости, делайте как можно меньше E2E-тестов. Пишите один E2E-тест на десять других, и лишь тогда, когда они действительно необходимы.
Пишем E2E-тесты
Перейдём к написанию E2E-тестов. Нам нужны две вещи: браузер и сервер для нашего фронтенд-кода.
Сперва взглянем на настройку веб-сервера.
Настройка веб-сервера в Mocha
Веб-сервер на Node? На ум сразу же приходит express, давайте посмотрим код:
В функции before мы создаем express-приложение, указываем ему папку dist и прописываем слушать порт 8080. В функции after мы «убиваем» сервер.
Папка dist — это то место, где мы храним наши JS-скрипты и куда копируем HTML- и CSS-файлы. Вы можете увидеть, что мы делаем это в сборочном скрипте npm в package.json :
Папка dist используется как в пользовательском окружении, так и в E2E-тестах. Это важно — запускать E2E-тесты нужно в средах, максимально похожих на «боевые».
Настройка браузера в Mocha
Для начала давайте посмотрим, как мы используем её, прежде чем начнём разбираться с настройками:
Это сложная штука. И я должен кое-что признать: этот код был написан кровью (о, и он работает только в Unix-системах). Он был написан при помощи Google, Stack Overflow и документации webdriver и сильно модифицирован методом научного тыка. Но он работает!
Теоретически вы можете просто скопипастить код в свои тесты, не разбираясь в нём, но давайте заглянем в него на секунду.
Почему мы делаем это в строках 11–15? Причины скрыты туманом опыта. Не стесняйтесь копипастить — никаких гарантий не прилагается, но я использовал этот код некоторое время, и проблем не возникало.
Приступим к тестам
Мы закончили настройку — пришло время взглянуть на код, который использует webdriver для управления браузером и тестирования нашего кода.
Разберём код по частям:
Пропустим установку, которую мы видели раньше, и перейдем к самой тестовой функции.
Код переходит к приложению и проверяет, что его название — «Calculator». Первую строку мы уже видели — мы открываем наше приложение с помощью драйвера. И не забываем дождаться окончания процесса.
Перейдём к строке 9. Здесь мы просим браузер вернуть нам заголовок (используем await для ответа, потому что это асинхронно), а в строке 10 мы проверяем, что заголовок title имеет корректное значение.
Поиск элементов
Дальше, к следующей части теста!
В строке 10 с помощью метода getText() мы получаем содержимое элемента и проверяем его. Помните, что нужно дожидаться ( await ) выполнения всех методов!
Пользовательский интерфейс
Настало время тестировать наше приложение — нажимать на цифры и операторы и проверять результат операций:
Выполнение всех тестов
Итак, у нас есть E2E-тесты и юнит-тесты, запустим их с помощью npm test :
Про пользу E2E тестирования
В пирамиде тестирования End-to-End (E2E) тесты занимают одну из верхних ступеней. Написав один E2E тест, можно быть уверенным в результатах работы логики приложения, проверить интеграции с другими системами и создать «контракт» для вашего приложения.
К сожалению, многие из коллег, с которыми я работал, не писали E2E тесты. Отчасти потому что с головой ушли в модульное тестирование и посчитали, что оно лучше по ряду причин, включая моду на TDD. Отчасти потому что верили, что E2E тесты сложно писать, они долго исполняются, да и с инструментарием есть проблемы.
Разберемся с этими мнениями и посмотрим на плюсы, которые предлагает E2E тестирование.
Терминология
Под E2E тестами положим вид автотестов. Эти автотесты должны покрывать все функции сервиса с точки зрения клиента. Добиваются они этого, симулируя реальное взаимодействие клиента, будь это HTTP-запрос или нажатие на кнопку в UI.
Подход модульного тестирования лучше
Написание модульных тестов, по моему опыту, занимает куда больше времени, чем E2E тестов. Да, на первых порах придется разобраться как E2E тесты лучше писать, но ведь то же было верно и для модульных тестов.
Зато, в результате один E2E тест покрывает больше кода, чем один Unit-тест, хотя может занимать меньшее количество строк по сравнению с аналогичным модульным test suite.
Можно не тратить время на понимание того, как правильно мокировать зависимости, ведь ими становятся в E2E тестах внешние системы, а взаимодействие с тестируемым сервисом строится по принципу «черного ящика».
Не нужно проверять все граничные условия для отдельного метода класса. Это повышает гибкость работы с кодом, так как нет необходимости рефакторить весь test suite при малейшем изменении внутренней логики работы приложения.
Невозможно попасть в ситуацию, когда ты боишься выкинуть старый код, потому что придется пройтись по набору из 100 модульных тестов (написанных даже не тобой), которые так или иначе были завязаны на этот код.
Инструментарий и скорость прогона тестов
На сегодняшний день большинство backend-разработчиков пишут сервисы, представляющие API с помощью HTTP (возможно GraphQL) или некоторым подобием MQ. В таком случае достаточно обычного клиента HTTP, доступного в большинстве mainstream ЯП.
Frontend-разработчики пишут, в основном, для Web-платформ (браузеров) или для мобильных в виде нативных приложений. Тут ситуация немного сложнее, так как инструментарий требует более детального изучения, но не дольше любого остального инструмента, с которым Вам придется столкнуться при разработке приложений.
E2E тесты действительно требуют в среднем больше времени для прогона, нежели модульные. При этом они завязаны на скорость работы Вашей системы. Т.е. они становятся метрикой производительности отдельных операций. При необходимости, они могут просто преобразовываться в нагрузочные тесты.
Дополнительные плюсы E2E тестирования
Каждый отдельный тест покрывает реальный сценарий использования приложения и дает куда больше понимания другим разработчикам, в том числе и будущим, как именно и зачем все это работает.
По результатам работы Вы получаете «настоящий» code-coverage. Если есть код и его невозможно исполнить, выполняя клиентские запросы в реальном окружении, то, скорее всего, это лишний код. Если он проверяет граничные условия или ловит маловероятный exception, задумайтесь, возможны ли такие условия в принципе?
В целом, использование только E2E тестирования для приложения заставляет задуматься об упрощении структуры Вашей системы и улучшения документации.
E2E тесты могут использоваться как контракты API и взаимодействия с Вашим сервисом. К примеру, для backend, как только Ваш E2E тест меняется, необходимо убедиться, что frontend будет готов к таким изменениям.
Заключение
В целом, на мой взгляд, E2E тестирование предоставляет большие гарантии корректной работы системы, чем unit-тесты, большую гибкость в работе с кодом с точки зрения рефакторинга и отражает реальную суть работы приложения.
Спасибо Вам за внимание! А как Вы считаете, можно ли использовать только E2E тесты?
Цена регресса. Как мы организовали инфраструктуру для Е2Е-тестов
Мы, команда автоматизации Страхового Дома ВСК, подготовили небольшой рассказ о нашей инфраструктуре. Эта статья может быть входной точкой для специалистов, желающих внедрить автотестирование у себя в компании. Расскажем, какие системы, паттерны и фреймворки можно использовать, а также как интегрировать это в релизный цикл. Материал подойдёт как юным автоматизаторам, так и тем, кто желает поближе познакомиться с темой. Большое внимание уделим не только абстрактным вопросам, но и организации кода проекта. Добро пожаловать под кат.
Изложение поделено на две логические части. В первой опишем инфраструктуру и процесс, а во второй рассмотрим некоторые детали написания кода. Но для начала немного обрисуем рабочую среду:
задачи ведём в Jira;
тест-кейсы и тест-планы готовим в TestRail;
очередь запускаемых тестов определяется Sprut;
за деплой отвечает Azure DevOps;
за виртуалки в докере — Selenoid;
Кому и зачем нужна команда автоматизаторов
Очевидно, что компании стремятся к уменьшению релизного цикла разрабатываемого ПО. Для достижения этой цели команды разработчиков прибегают к различным гибким методологиям. Однако всё равно отделу контроля качества приходится раз за разом выполнять регрессионное тестирование, занимающее от нескольких дней до нескольких недель. Именно поэтому существуют такие команды, как наша, стремящиеся сократить время регресса за счёт автоматизации.
Т. к. команда ручного тестирования является нашим заказчиком, мы постарались максимально прозрачно интегрироваться в их процесс.
Страховой Дом ВСК использует TestRail как систему управления тестированием. Выполнение регрессионного тестирования сводится к следующим простым этапам:
Создание тестового плана, где выбирается необходимый список тестов. Сюда попадают как обычные, так и автоматизированные кейсы.
Запуск тестов. После создания плана наша система (о ней чуть позже) распознаёт автоматизированные кейсы, ставит их в очередь и результат прогона возвращает обратно в TestRail.
Получение результатов. После завершения всех тестов тестлид видит общий отчёт по состоянию ручного и автоматического тестирования.
Анализ результатов. В том случае, если автотест упал по неизвестной причине, пользователь может посмотреть результат и при необходимости пройти кейс вручную, либо дождаться исправления.
Инфраструктура и автотестовый дашборд
Как уже упоминалось, процессом запуска автотестов руководит отдельная система. Многие компании предпочитают разрабатывать подобную инфраструктуру самостоятельно, чтобы лучше контролировать процесс. Мы не исключение, поэтому знакомьтесь со Sprut.
В первую очередь на Sprut возложена работа с очередью запускаемых тестов, мониторингом и управлением процессами. (За деплой отвечает Azure DevOps, а за виртуалки в докере — Selenoid. В будущем планируем внедрить автодеплой при запуске.) Также Sprut выполняет постобработку результатов прогонов: классификацию и кластеризацию. Из-за того, что тестам свойственно падать пачками, Sprut предоставляет прогон тестплана в сгруппированном по ошибкам виде. Автотестеру проще работать с такой системой, чем с TestRail.
Для каждого упавшего теста можно посмотреть логи, скриншоты и другие артефакты. Если тест упал из-за Assert, система относит инцидент к категории «Ошибка ПО» (т. е. не прошла целевая проверка). В силу природы самих Е2Е-тестов падения, которые случились не в секции Assert, попадают в отдельную категорию, где дежурный разработчик тестов уже проводит анализ, т. к. нельзя однозначно определить, это «Ошибка в автотесте» или «Ошибка ПО».
В ходе анализа Sprut позволяет сразу создать тикет в Jira и назначить ответственного. После исправления автотестов система позволяет выполнить перезапуск не прошедших ранее кейсов, а результат аккумулируется с предыдущим раном в тестовом плане. Так за несколько итераций мы можем разобрать все проблемы.
О сложности Е2Е-тестов
Проект автотестов — это такой же программный продукт, код которого нужно писать и поддерживать. И этот код следовало бы тоже тестировать, но тогда мы войдём в бесконечную рекурсию (тесты, которые тестируют тесты, которые тестируют. ). Е2Е-тесты по своей сути обеспечивают самый высокий уровень защиты от багов, но являются очень хрупкими и нестабильными. Поэтому мы подошли к архитектуре со всей ответственностью и разработали структуру, о которой дальше пойдёт речь.
Наш способ организации проекта позволяет бороться с усложнением системы, возникающим из-за увеличения числа автоматизированных тестов.
Для наглядности предлагаю разработать автотест для следующего упрощённого кейса:
Пользователь заходит на страницу поиска авто.
Вбивает несуществующий, но валидный номер паспорта ТС (транспортного средства).
Указывает регистрационный номер ТС.
Ожидаемый результат: появляется сообщение с предупреждением «Автомобиль не существует в базе».
Модель данных
В нашей системе модель содержит всю необходимую для выполнения теста информацию. Мы выделяем два основных типа моделей:
Являются композицией общих моделей и включают некоторую служебную информацию теста и специфичные данные для конкретного тестового метода (например, TestID).
Создадим для нашего примера общую модель:
Обратите внимание, что значение свойства по умолчанию генерируется случайным образом. Такой подход позволяет нам избегать коллизий и тестировать систему с широким диапазоном входных данных.
А регистрационный номер не является обязательным и, раз не задан, не станет подставляться в поле поиска по умолчанию. Модель менеджера будет включать в себя только одно свойство:
ModelBase содержит определение служебных полей: TestID, Login, Password. Но прежде чем мы перейдём к написанию теста — ещё пара слов о модели.
Для каждого тестового метода мы подготавливаем отдельный XML-файл, который будет десериализоваться в конкретный объект, переопределяя интересующие свойства. Так, для нашего теста создадим файл, где будет переопределённый ID теста:
В большинстве случаев нас будут устраивать значения свойств по умолчанию. Но если тесты похожи, мы можем переиспользовать тестовый метод путём вставки в XML дополнительных блоков. В XML мы указываем только специфичные для данного теста свойства. Этот трюк во многом облегчает поддержку: для изменения входных данных не требуется знаний языка программирования и можно безболезненно расширять модели CarFindData и CarData.
Например, в следующем примере, указав дополнительные наборы данных в той же XML, мы получили новые тесты, ничего не меняя в коде, и можем запускать их отдельно при необходимости.
Тестирование UI
Мы выделяем три основных типа объектов:
Тестовый класс. Содержит тестовые методы, схожие по шагам и тестовым параметрам.
Менеджер. Предоставляет набор законченных логических операций — шагов теста в конкретной области приложения или отдельных проверок результатов.
FormObject/PageObject/APIObject. Инкапсулируют сложность взаимодействия с интерфейсом, предоставляя атомарные действия над элементами страницы. Для APIObject это может быть поиск конкретных значений по тегам в ответе сервиса.
Теперь напишем код теста для нашего примера:
Мы разбиваем тестовый метод на два этапа. Этап подготовки данных читает XML-файл, который мы создали ранее, и возвращает список десериализованных моделей. Метод NotFoundWarningWhenNotFoundCarTest будет запущен для каждой модели из списка, что позволяет автоматизировать сразу несколько похожих тест-кейсов, используя один и тот же код.
Для описания последовательности шагов мы пользуемся Fluent-синтаксисом, что в совокупности с IntelliSense делает написание кода таким же лёгким, как и его чтение. Main.Manager является точкой входа для работы с любыми другими менеджерами. Код в нём может содержать действия корректной инициализации и будет специфичен для каждого отдельного приложения. Его мы рассматривать не будем и перейдём сразу к созданию менеджера страницы поиска автомобиля:
Менеджеры должны отделять действия от проверок, предоставляя для этого различные методы. Метод принимает модель данных и сам определяет, какие свойства ему нужны. Допускается, что менеджер может изменять модель для того, чтобы передать какую-либо информацию другой части теста.
Реализация CarFindPage зависит от конкретного типа приложения. В наших проектах мы используем два богатых фреймворка: Selenium (для работы с браузером) и FlaUI (для тестирования WinForm). Более подробно о них вы можете узнать в других статьях на Хабре.
Итак, мы рассмотрели в общем виде структуру наших проектов. Хороший автотест должен содержать простой, понятный и стабильный код. А каждый метод — писаться с мыслью о повторном использовании в будущем. Такая архитектура позволяет успешно масштабировать количество тестов за счёт переиспользования кода. Чтобы с ростом проекта код оставался таким же чистым, нужно не забывать о таких практиках, как:
обязательное code review,
единый code style и конвенция наименования типов.
Пишем логи правильно
Ещё одна важнейшая характеристика автотеста — его максимальная прозрачность и понятность. Т. к. с результатами прогона теста работают не только его создатели, требуется, чтобы ошибка была понятна и тестировщику, и разработчику без дополнительных пояснений. Это экономит гигантское количество времени для всей компании.
Добиваемся данной цели следующими способами:
отделяем целевые проверки от шагов,
автоматически делаем скриншот в момент падения теста,
логируем каждое действие теста.
Первые два пункта более-менее очевидны, а про третий мы бы хотели рассказать поподробнее. Вот так выглядит наш файл с логом:
Помимо этого лога формируется лог для Allure
Такой лог очень легко прочесть. Как можно заметить, в него попадают шаги вышеупомянутых менеджеров и действия с FormObject. Чтобы наглядно продемонстрировать, как в коде выглядит объявление этих шагов, модифицируем наш предыдущий пример:
Нам всего лишь пришлось добавить один атрибут и обычные комментарии к методам. Атрибут TraceAspect сообщает, что для данного класса нужно сгенерировать код, отвечающий за логирование шагов. Такой трюк возможен с помощью NuGet-пакета Aspect Injector. А сам текст шага будет взят из XML-документации, которую можно сгенерировать на этапе билда.
Аналогичным способом реализуются и другие часто повторяющиеся операции. Например, есть аспект для проверки передаваемых аргументов на null в методы страницы.
Для добавления этого функционала к любому PageObject необходимо прописать аннотацию [NotNullArgumentAspect] к этому классу.
Алгоритм работы следующий:
Если применено не к наследнику PageBase — будет вызвано исключение.
Если метод не публичный, или тип результата метода не совпадает с PageObject, в котором хранится метод, или если это вообще не метод, а LINQ-запрос — управление передаётся методу без дополнительных проверок.
Проверяются все аргументы, переданные в метод. Если хотя бы один из них равен null — записывается сообщение в лог и метод не выполняется (возвращается корректный PageObject). Если с аргументами всё хорошо — метод выполняется.
Подводим итоги
Суть автоматизации, как и разработки любого продукта, — сделать систему, позволяющую упростить и ускорить работу пользователей. Мы считаем, что успешно справились с данной задачей, т. к. построили инструмент, которому тестировщики доверяют и который активно используют. На этом наша работа ещё не закончена: в ближайших планах есть много интересных задач по улучшению. Например, чтобы в момент запуска теста в Docker-контейнере автоматически стартовало динамическое развёртывание и тестовый проект сразу подстраивался под среду, указанную в параметрах запуска.
Мы постарались показать вертикальный срез нашей инфраструктуры тестирования. Невозможно в рамках одной статьи рассказать обо всех нюансах. Мы готовы ответить на ваши вопросы в комментариях и будем рады, если вы расскажете о своих техниках: как справляетесь с теми или иными проблемами.
Сквозные тесты
Dec 8, 2019 · 7 min read
Несколько слов о сквозных тестах.
О чем статья
Статья в больше степени будет описывать сквозные тесты. Будет описан процесс, реализованный в последнем моем проекте. Также статья балы написана как предложение развития автоматизациия тестирования в компании, которой я работаю.
Для чего нужны e2e тесты
Сквозное, end-to-end — это тестирование системы в целом, эмулируя реальную пользовательскую среду. Это тесты, запущенные в браузере, имитирующие щелчки мышью и нажатия клавиш. Сквозным оно называется, потому что проверяют бизнес функции системы. Если брать терминологию тестирования, то e2e — это поведенческое тестирование по методу «чёрного ящика» (проверка выполнения приложением заданных функциональных требований, при которой не используются знания о внутренней структуре тестируемого объекта). То есть мы тестируем, что система работает, как планировалось, с точки зрения конечного пользователя.
Пользователю всё равно, работает ли приложение «как планировалось», ему важно, чтобы функционал работал в соответствии с его собственными ожиданиями. Тестирование по сути это автоматизированный запуск приложения в браузере и последовательные действия, проверяющие весь функционал пользовательского интерфейса. Совершать все эти действия вручную было бы крайне неэффективно, поэтому создадим автоматические тесты.
В итоге тесты нужны для следующих вещей:
Пирамида тестирования
Вспомним пирамиду тестирования, где показывается распределение по типам тестов в приложении.
На написание и запуск E2E-тестов требуется время и ресурсы. Google например предлагает разделение 70/20/10: 70% unit тестов, 20% интеграционных тестов и 10% E2E-тестов. Точная комбинация будет отличаться для каждого проекта, но в целом она должна сохранить форму пирамиды.
Из пирамиды, как мы знаем, следует что тестов необходимо писать малое количество, это объясняется следующими причинами:
1. Хорошо написанных интеграционных и юнит-тестов должно хватить. E2E-тесты должны проверить, что все элементы корректно связаны между собой.
2. Скорость выполнения. Если их будет сотни, как юнит-тестов и интеграционных, то тестирование будет проходить очень долго.
3. Непредсказуемость. Так как имитируется пользовательская среда, то в таймаут могут не проходить некоторые тесты из-за API браузера. С юнит(интеграционными) тестами такого быть не может.
Когда использовать e2e тесты
По хорошему, e2e-тесты стоит использовать в каждом проекте, в котором есть команда(dev, qa, pm). Но стоит отметить, что внедрять e2e тесты стоит использовать только когда покрыты unit тесты и интеграционные, только тогда будет понятно, что еще не покрыто в системе. Также необходимо учитывать возможность написания тестов, если проект короткий mvp, то нет смысла писать сквозные тесты, так как большая часть функционала может быть переписана и переделана.
Виды тестирования
Перед тем как говорить о сквозных тестах, стоит понимать к какому виду тестирования он относится и какое место он занимает. Классификация тестов обширная и всю ее мы приводить не будем.
Знание системы
Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа, которое может охватывать сразу несколько смежных техник тестирования. То есть, одному типу тестирования может соответствовать несколько его видов. Рассмотрим, для начала несколько типов тестирования, которые отличаются знанием внутреннего устройства объекта тестирования.
По целям
Таким образом сквозные тесты являются функциональными тестами методом черного ящика. Стоит это учитывать при разработке теста.
Unit vs E2E
Между модульными тестами и сквозными много отличий и часто возникает вопрос какие тесты использовать. Ответ очевиден использовать и оба вида тестов в соответствии с пирамидой тестирования. Все же стоит уточнить разницу между этими видами.
Модульные тесты:
Сквозные тесты:
Концепции
Создание e2e начинается с описания пользовательской истории. Насколько тщательно мы подготовим описание на этом этапе, настолько просто будет команде разработчиков написать E2E-тест, который будет демонстрировать что все системы работают правильно при реализации этого сценария. Спустя какое-то время, технические писатели или новая команда разработчиков, вместо чтения документации, могут воспользоваться тестами, для того чтобы запустить и посмотреть реализованные сценарии в реальном браузере или автоматически записать видео-уроки.
Жизненный цикл сквозного теста следующий:
Как все устроено
Запуск тестов возможен двумя способами: через ci в автоматическом режиме, либо локально на машине разработчика. Сами тесты запускаются с помощью фреймворка, который в совокупности в веб-драйвером составляют движок автоматизации e2e, который может генерировать отчет о выполнении, также движок запускает браузер и взаимодействует с ним(отправляет команды, запускает тесты), браузер в свою очередь запускает тестируемое приложение, которое взаимодействует в бекендом. Бекенд в стандартной манере взаимодействует в БД, в этом плане ничего не меняется, связка приложения и бекенда с БД, остается неизменным. Также движок автоматизации должен хранить в актуальном состоянии БД перед запуском каждого теста.
Protractor
Protractor — это программа Node.js, построенная поверх WebDriverJS. Protractor работает как интегратор решений, объединяющий мощные технологии, такие как Node.js, Jasmine, Selenium, Mocha, Cucumber и Web.
Каждый тест представляет собой два файла для теста страницы (spec и po). Ниже представлен код проверяющий заголовок на конкретный текст.
Каждая страница оборачивается в тестовую группу describe и каждый тест-кейс обозначается через it — синтаксис аналогичен Jasmine. Каждый элемент страницы ищется через встроенные в фреймворк методы. Все методы асинхронные, это стоит учитывать при разработке, чтобы тесты выполнялись стабильно.
Весь повторяющийся код переводится в beforeEach, если код специфичный для конкретных тестов, то он выносится в page Object. Так как protractor использует Selenium, то по умолчанию используется паттерн Page Object.
Page Object Pattern
Page Object активно используется при разработке тестов и стоит понимать почему именно этот шаблон проектирования используется в protractor. Page Object это шаблон проектирования, который широко используется в автоматизированном тестировании и позволяет разделять логику выполнения тестов от их реализации.
Style guide
Стайл гайд взят из https://www.protractortest.org/#/style-guide. В статье указаны правила, которые используются в наших проектах.
Автоматизация на проектах
1. Выбрать фреймворк для тестирования. В нашем случае мы выбрали protractor, так как он по умолчанию встроен в Angular, но также можно выбрать другой фреймворк, но мы пошли по меньшему сопротивлению. В других средах, необходимо выбирать фреймворк для тестирования.
2. Выбрать основные тесты. Так как мы определились что мы не можем использовать много e2e тестов из-за их дороговизны в разработке и скорости выполнения, поэтому необходимо выбрать костяк основной функциональности системы, которая должна обязательно выполняться.
3. Интеграция CI/CD. Этот шаг очень важен, так как тесты обязательно должны запускаться автоматически и не должны попадать ан стенд не оттестированные разработчиком. Этот пункт касается не только e2e тестов но и всей кодовой базы.
Сквозные тесты внедрены в пайплайн сборки, но могут валится(решается внедрением докера). Составлены предложения по развитию автоматизации тестирования. Кроме того необходимо больше проектов, где возможно внедрить сквозные автотесты. Но стоит отметить, что перед внедрением тестов стоит учитывать, что нужны устаканенные ТЗ и тест-кейсы с пользовательскими сценариями.