что такое сквозное тестирование e2e
Про пользу 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 тесты?
End-to-end или E2E-процесс: что это? Сквозное тестирование
и другие поведенческие факторы.
К примеру, компания Гугл при разработке своих продуктов следует правилу «70-20-10», цифры которого показывают процентное соотношение от общего количества тестов, то есть:
70% занимают юнит-тесты;
20% занимают интеграционные тесты;
Нет единого алгоритма сквозного тестирования, так как многое будет зависеть от сложности самого проекта и что конкретно нужно тестировать. Е2Е — это лишь название процесса тестирования, а не его метод или алгоритм. Но при этом выделяют два основных типа сквозного тестирования, на которых мы немного остановимся.
Любой сквозной тест — это:
в первую очередь тестирование UI;
тяжелый и медленный тест;
применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы;
тяжелый «отлов» найденной проблемы;
тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»;
Заключение
нагрузку на каждый трос или балку;
поведение моста при наводнении, землетрясении, пожаре или аварии на нем;
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Просто скажите «нет» end-2-end тестам
У вас наверняка было такое, когда вы и ваши друзья очень хотели посмотреть какой-нибудь фильм, а после жалели о том, что потратили на него время. Или, может быть, вы помните тот момент, когда ваша команда думала, что нашла «киллер фичу» и обнаруживала ее «подводные камни» только после выпуска продукта.
Хорошие идеи часто терпят неудачу на практике, и в мире тестирования хорошим примером этого может служить стратегия тестирования, построенная на автоматизации end-to-end тестов.
Тестировщики могут инвестировать свое время на написание многих типов автоматических тестов, включая модульные тесты, интеграционные тесты и end-2-end тесты, но эта стратегия в основном направлена на end-2-end тесты, которые проверяют продукт или услугу в целом. Как правило, эти тесты имитируют реальные пользовательские сценарии.
End-2-end тесты в теории
Хотя полагаться в первую очередь на end-2-end тесты — плохая идея, но теоретически можно придумать несколько доводов в пользу этого утверждения.
Итак, номер один в списке Google из десяти вещей, которые, как мы знаем, являются правдой: «Интересы пользователей превыше всего». Таким образом, использование end-2-end тестов, которые фокусируются на реальных пользовательских сценариях, выглядит отличной идеей. Кроме того, эта стратегия в целом привлекательна для многих участников процесса.
End-2-end тесты на практике
Итак, если эта стратегия тестирования выглядит так хорошо в теории, то что же с ней не так на практике? Чтобы продемонстрировать это, я ниже приведу выдуманный сценарий, но который основан на реальных ситуациях, знакомых как мне, так и другим тестировщикам.
Допустим команда создает сервис для редактирования документов в режиме онлайн (например, Google Docs). Давайте предположим, что у команды уже есть какая-то фантастическая инфраструктура для тестирования. Каждую ночь:
Несмотря на многочисленные проблемы, тесты в конечном итоге выявили реальные ошибки.
Ошибки, влияющие на пользователя, были выявлены и исправлены до того, как они к нему попали.
Истинная ценность тестов
Как правило, работа тестировщика заканчивается, когда тест провален. Ошибка регистрируется, и затем задача разработчика — исправить ошибку. Однако чтобы определить, где end-2-end стратегия не срабатывает, нам нужно выйти за рамки этого мышления и подойти к проблеме используя наши базовые принципы. Если мы «сосредоточимся на пользователе (а все остальное приложится)», мы должны спросить себя: приносит ли проваленный тест пользу пользователю?
Вот ответ: «Проваленный тест напрямую не приносит пользы пользователю».
Хотя это утверждение, на первый взгляд, кажется шокирующим, оно верно. Если продукт работает, он работает, независимо от того, говорит ли тест, что он работает или нет. Если продукт сломан, он сломан, независимо от того, говорит ли тест, что он сломан или нет. Итак, если проваленные тесты не приносят пользы пользователю, то что же приносит ему пользу?
Исправление ошибок напрямую приносит пользу пользователю.
Пользователь будет счастлив только тогда, когда это непредсказуемое поведение (ошибка) исчезнет. Очевидно, чтобы исправить ошибку, вы должны знать, что она существует. Чтобы узнать, что ошибка существует, в идеале у вас должен быть тест, который ее обнаруживает (потому что если тест не выявит ошибку, то ее найдет пользователь). Но во всем этом процессе, от провала теста до исправления ошибки, добавленная стоимость появляется на самом последнем шаге.
Таким образом, чтобы оценить любую стратегию тестирования, вы не можете просто оценить, как она находит ошибки. Вы также должны оценить, как это позволяет разработчикам исправлять (и даже предотвращать) их.
Построение правильной обратной связи
Тесты создают цикл обратной связи, который информирует разработчика о том, работает продукт или нет. Идеальный цикл обратной связи имеет несколько свойств.
Думайте о малом, а не о большем
Так как же нам создать этот идеальный цикл обратной связи? Думая о малом, а не о большем.
Модульное тестирование
Модульные тесты берут небольшой фрагмент продукта и тестируют его изолированно от всего остального. Они почти создают тот самый идеальный цикл обратной связи:
Модульные тесты против end-2-end тестов
При end-2-end тестах вам нужно подождать: сначала создания всего продукта, затем его развертывания и, наконец, выполнения всех end-2-end тестов. Когда тесты все же заработали, вероятнее всего, они периодически будут сбоить. И даже если тест обнаружит ошибку, она может быть в любом месте продукта.
Хотя сквозные тесты лучше справляются с моделированием реальных пользовательских сценариев, это преимущество быстро перевешивается всеми недостатками сквозного цикла обратной связи:
Интеграционные тесты
У модульных тестов есть один существенный недостаток: даже если модули работают хорошо по отдельности, вы не знаете, хорошо ли они работают вместе. Но даже тогда вам не обязательно проводить end-2-end тесты. Для этого вы можете использовать интеграционный тест. Интеграционный тест берет небольшую группу модулей, часто два, и тестирует их поведение как единого целого.
Если два блока не интегрируются должным образом, зачем писать сквозной тест, когда вы можете написать гораздо меньший, более сфокусированный интеграционный тест, который обнаруживает ту же ошибку? Конечно, вы должны понимать весь контекст при тестировании, но для того, чтобы проверить работу двух модулей вместе вам всего лишь нужно совсем чуть-чуть расширить перспективу.
Пирамида тестов
Даже при проведении и модульных, и интеграционных тестов вам, скорее всего, потребуется небольшое количество end-2-end тестов для проверки системы в целом. Чтобы найти правильный баланс между всеми тремя типами тестов, лучше всего использовать визуальную пирамиду тестирования. Вот упрощенная версия пирамиды тестирования из вступительной речи конференции Google Test Automation 2014 года.
Основная часть ваших тестов — это модульные тесты в нижней части пирамиды. По мере того как вы продвигаетесь вверх по пирамиде, ваши тесты становятся более всеобъемлющими, но в то же время количество тестов (ширина вашей пирамиды) уменьшается.
По-хорошему, Google предлагает разделение 70/20/10: 70% модульных тестов, 20% интеграционных тестов и 10% end-2-end тестов. Точное соотношение будет отличаться для каждой команды, но в целом она должна сохранять форму пирамиды. Старайтесь избегать следующих «форм»:
End-to-end тестирование микросервисов c Catcher
Добрый день! Я хотел бы представить новый инструмент для end-to-end тестирования микросервисов – Catcher
Зачем тестировать?
Зачем нужно e2e тестирование? Мартин Фаулер рекомендует избегать его в пользу более простых тестов.
Однако, чем выше находятся тесты — тем меньше переписывать. Юнит тесты переписываются почти полностью. На функциональные тесты также приходится тратить свое время в случае серьезного рефакторинга. End-to-end тесты же должны проверять бизнес логику, а она меняется реже всего.
К тому же, даже полное покрытие тестами всех микросервисов не гарантирует их корректного взаимодействия. Разработчики могут неправильно имплементировать протокол (ошибки в наименовании/типе данных).
Или реализовать новый функционал полагаясь на схему данных из документации, а на продуктовом окружении получить сюрприз в виде ошибок несоответствия схем: бардак в данных либо кто-то забыл обновить схему данных.
И тесты каждого из задействованных сервисов будут зеленые.
А зачем автоматическое тестирование?
Действительно. На моем предыдущем месте работы решили, что тратить время на разворачивание автоматических тестов это слишком долго, сложно и дорого. Система не большая (10-15 микросервисов с общей кафкой). CTO решил, что «тесты не важны, главное чтобы система работала». Тестировали вручную на нескольких окружениях.
Как это выглядело (общий процесс):
А теперь немного дегтя в эту бочку с шоколадом: на большинство тестов нужно было создавать пользователей, потому что переиспользовать существующих сложно.
Во-первых, из-за того, что система распределенная — у нескольких сервисов были свои базы данных, в которых лежала информация о пользователях.
Во-вторых, кафка использовалась для постоянного хранения данных. Т.е. даже если информацию удалить/изменить в базе данных, сервис при перезагрузке все-равно прочитает ее обратно.
Как выглядела регистрация нового тестового пользователя (приблизительно):
Супер, пользователь зарегистрирован! Теперь еще немного дегтя: для некоторых тестов нужно больше чем 1 тестовый пользователь. И иногда с первого раза тесты не проходят.
А как происходит проверка нового функционала и подтверждение со стороны бизнес-команды?
Все то же самое нужно повторить на следующем окружении.
Нужно ли говорить, что через некоторое время начинаешь ощущать себя мартышкой, которая только и делает что нажимает кнопки, регистрируя пользователей.
Еще у некоторых разработчиков (обычно у фронт-энда) были проблемы с подключением к кафке. И с багом в терминале при строке 80+ символов (не все знали про tmux).
Плюсы:
Минусы:
Как автоматизировать?
Если вы дочитали до сюда кивая головой и приговаривая: «да, отличный процесс, парни знают что делают», то дальше вам будет не интересно.
Самодельные e2e тесты бывают двух типов и зависят от того, какой из программистов был более свободен:
Звучит неплохо. Проблемы?
Да, такие тесты пишутся на том, что знает тот, кто их пишет. Обычно это скриптовые языки вроде руби или питон, которые позволяют быстро и просто написать подобного рода вещь. Однако, иногда можно наткнуться на ворох баш-скриптов, Си или что-то более экзотическое (я потратил неделю, переписывая велосипед на баш скриптах на питон, потому что скрипты уже были не расширяемыми и никто толком не знал как они работают и что тестируют).
Пример проекта здесь
Плюсы:
Минусы:
Есть что-нибудь готовое?
Конечно, достаточно посмотреть в сторону BDD. Есть Cucumber, есть Gauge.
Если кратко – разработчик описывает бизнес сценарий на специальном языке, после реализует шаги сценария в коде. Язык как правило человекочитаемый и предполагается что его будут читать/писать не только разработчики, но и менеджеры проектов.
Сценарии вместе с реализацией шагов также находятся в отдельном проекте и запускаются сторонними продуктами (Cucumber/Gauge/…).
Сценарий выглядит так:
Плюсы:
Минусы:
Ну и зачем тогда Catcher?
Разумеется, чтобы упростить процесс.
Разработчик пишет только сценарии в json/yaml, а Catcher их выполняет. Сценарий состоит из последовательно выполняемых шагов, например:
Catcher поддерживает jinja2 шаблоны, так что можно использовать переменные вместо зашитых значений в примере выше. Глобальные переменные можно хранить в инвентарных файлах (как в ансибле), подтягивать из окружения и регистрировать новые:
Дополнительно можно запускать проверочные шаги:
Также можно запускать одни скрипты из других скриптов, что отлично сказывается на чистоте и повторном использовании кода (включая запуск только части шагов через систему тегов, отложенный запуск и т.п. плюшки).
Вставка и использование скриптов могут решить проблему ожидания ресурса (ждать сервис, пока он стартует).
Помимо готовых встроенные шагов и дополнительного репозитория) есть возможность писать свои модули на питоне (просто наследуя ExternalStep) или на любом другом языке:
Сценарии помещаются в докер файл и запускается через CI.
Также этот образ может быть использован в Marathon/K8s для тестирования существующего окружения. На данный момент я работаю над бэкэндом (аналог AnsibleTower), чтобы сделать процесс тестирования еще проще и удобнее.
Плюсы:
Минусы:
Вместо заключения
Когда я писал этот инструмент, я просто хотел сократить время, которое я обычно трачу на тесты. Так получилось, что в каждой новой компании приходится писать (или переписывать) такую систему.
Однако инструмент получился гибче, чем я предполагал. Если кого-то заинтересует статья (или сам инструмент), я могу рассказать, как использовать Catcher для организации централизованных миграций и обновления системы микросервисов.
Как мне указали в комментариях, тема не раскрыта.
Попытаюсь указать здесь наиболее спорные тезисы.
Внедрение E2E-тестирования с Puppeteer и Jest
Хотим поделиться краткой историей о том, как мы на одном из проектов «Рексофт» пришли к написанию автотестов, и почему сделали акцент именно на e2e-тестах.
Речь пойдет о работе с порталом крупного федерального заказчика, работающего в сфере B2B и B2C, имеющего серьезный трафик из всех регионов. Сайт писал не «Рексофт». Ресурс попал к нам на поддержку какое-то время назад. Изначально проект содержал довольно много легаси кода, тестов не было, как и документации. Требовалось сделать редизайн по новым макетам, параллельно расширяя существующую функциональность. Обычная история.
В какой-то момент мы поняли, что ручное прокликивание интерфейса стало занимать очень много времени, и решили, что пришло время для автотестов.
Перед выбором подхода к автотестам классифицировали баги по типу: их большая часть касалась именно бизнес-логики (Javascript). Багов, связанных с кроссбраузерностью или вёрсткой, было не очень много.
Итак, цель была поставлена — автоматизировать проверку бизнес-логики, т.е. заполнение и отправку форм, работу слайдеров и т.д.
В качестве базового фреймворка для тестов был выбран Jest, а для имитации действий пользователя — Puppeteer. Последний выбрали благодаря тому, что он поддерживается Google и имеет отличную документацию. Нам было вполне достаточно тестов в одном браузере (Chrome) (хотя, есть инструменты, позволяющие с помощью Puppeteer запускать тесты и в других браузерах, например, Firefox и IE). Playwright тогда ещё не было, а Selenium, чисто субъективно, казался более сложным в развертывании.
Далее кратко опишу преимущества и недостатки e2e-тестов.
Недостатки e2e-тестов
Относительно высокая сложность написания. Нужно обладать определёнными навыками, чтобы написать компактный и легкочитаемый e2e-тест.
Проблема закопаться. Я точно знаю, что желание проверить всё и вся, может привести к написанию огромного количества избыточных тестов. Как побороть эту проблему? Не стоит пытаться протестировать абсолютно все возможные кейсы, достаточно сосредоточиться на основных.
Низкая скорость прохождения тестов (в сравнении с юнит-тестами). Довольно много времени тратится на запуск браузера, ожидание загрузки страницы, завершения анимаций и прочее. Для ускорения прохождения тестов потребуется свести к минимуму число пользовательских действий, а также число загрузок новых страниц.
Ускорить прохождение тестов можно, запуская их параллельно. В этом поможет Browser Context в Puppeteer.
Число параллельно запускаемых тестов в Jest регулируется флагом —maxWorkers.
«Хрупкость» e2e-тестов. Что я имею ввиду? Случай, когда тест падает без видимых на то причин, а при повторном запуске успешно выполняется, или же когда к падению теста приводит незначительное изменение в верстке. С хрупкостью тестов можно бороться с помощью автоматического перезапуска теста после падения. Помогут в этом раннер jest-circus и параметр retryTimes. Это практически полностью решает проблему “ложных” падений тестов.
Преимущества e2e-тестов
Гарантии. С e2e-тестами вы получаете определенные гарантии того, что система в целом работает корректно. Юниты такой гарантии не дают. Разумеется, это не значит, что вы получаете 100% гарантию того, что у вас работает абсолютно всё. Но вы будете уверены, что по крайней мере протестированные сценарии точно работают.
Снижение рабочей нагрузки. Без тестов разработчик вынужден думать — «как бы чего не сломать». Ведь не прокликивать же весь проект после очередного коммита с правками! С тестами вы узнаете о поломке еще до того, как код будет залит на стенд.
Ускорение разработки. Благодаря снижению количества багов и устранению ручных проверок интерфейса, серьезно экономится время. Причём e2e-тесты экономят не только ваше время, но и время тестировщиков (позволяя им заводить меньше багов, меньше коммуницировать, выясняя их детали и т. д.), время аналитиков (понятные тесты — отличная документация, отвечать на вопросы аналитиков вы будете намного быстрее).
Ускорение рефакторинга. При рефакторинге js, e2e-тесты не придется переписывать. Да и рефакторинг в вёрстке тоже редко приводит к их переписыванию.
Нет зависимости от кодовой базы и js-фреймворка. Вы можете написать e2e-тесты даже к легаси коду, что поможет быстрее его отрефакторить. При этом вы практически не зависите от js-фреймворка, т.к. в тестах оперируете только сущностями браузера.
Лайфхаки
1. Для ускорения написания первых тестов можно записывать действия пользователя с помощью Headless recorder или с помощью встроенных в Chrome инструментов.
2. Если требуется проверить несколько наборов данных в рамках одного кейса и руки тянутся написать for внутри теста, используйте jest-each. Эта библиотека позволит прогнать несколько наборов данных в одном кейсе, сохранив читаемость кода:
3. В случае возникновения ошибок, puppeteer не всегда корректно подсвечивает строку с ошибкой. Поэтому следует проверить код перед ошибочной строкой, часто ошибка кроется именно там.
4. Puppeteer позволяет запускать браузер с различными флагами, что иногда очень полезно (chrome://flags/). Ниже пример запуска браузера с отключенным флагом SameSite by default cookies
В качестве заключения
Написание e2e-тестов занимают около 5-10% от времени написания фичи. На фиксы багов уходило сильно больше времени, так что оно того стоило. Несмотря на ряд недостатков, e2e-тесты позволяют значительно ускорить процесс разработки и обрести уверенность в том, что основная функциональность системы работает.
Разумеется, при внедрении e2e-тестов для фронтенда необходимо учитывать специфику вашего проекта. Спасибо за внимание!