Что такое e2e тестирование
Сквозное тестирование (end-to-end): особенности и инструменты
Что такое E2E тестирование? Разбираемся с определениями и подбираем инструментарий.
E2E тесты обычно выполняются после всех остальных типов тестирования
У этой записи один комментарий
Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика – это совсем другое понятие.)
Для понимания сути этого понятия хорошо сравнить его с модульным (“нижний” уровень) и интеграционным (“средний”) тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных “модулей”, если их собрать вместе согласно архитектурe. Например, работает ли правильно “Корзина”, состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или “Корзина”, подключенная к “Вебморде” и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа…
И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через “Вебморду” и проверили сброс мыла на SMTP – все зашибись!). Однако, если настройки и эксплуатация SMTP сервера – часть проекта (например, заказана разработка webshop “под ключ”), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя… короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)
Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими – зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.
Про пользу 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 тесты?
Знакомство с фронтенд-тестированием. Часть третья. E2E-тестирование
Рассказывает Гил Тайяр, автор блога на Hackernoon
В этой части мы рассмотрим сквозное (E2E) тестирование: протестируем всё приложение целиком, причём сделаем это с точки зрения пользователя, по сути, автоматизируя все его действия.
В нашем случае приложение состоит только из фронтенда — бэкенда попросту нет, поэтому E2E-тестирование будет заключаться в открытии приложения в реальном браузере, выполнении набора вычислений и проверке валидности значения на экране.
Нужно ли проверять все перестановки, как мы делали это в юнит-тестах? Нет, ведь это уже проверено! В E2E-тестах мы проверяем работоспособность не отдельных юнитов, а всей системы сразу.
Сколько нужно E2E-тестов?
Первая причина, по которой таких тестов не должно быть много, — хорошо написанных интеграционных и юнит-тестов должно хватить. E2E-тесты должны проверить, что все элементы корректно связаны между собой.
27–29 декабря, Онлайн, Бе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 :
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 для организации централизованных миграций и обновления системы микросервисов.
Как мне указали в комментариях, тема не раскрыта.
Попытаюсь указать здесь наиболее спорные тезисы.
Эффективное тестирование верстки
Тестировать полезно. Тесты позволяют в автоматическом режиме безопасно рефакторить код и гарантируют его работу. Тесты – это живая документация: если информация в Wiki или в Confluence может устареть, то тесты всегда актуальны. Также многие крутые практики связаны с тестированием. Например, самотестирующийся код или разработка через тестирование (TDD), когда тесты пишутся перед кодом, а некоторые практики DevOps и Extreme Programming применимы только в условиях хорошего покрытия проекта тестами.
Но написать простые тесты, которые будут помогать в написании кода и не срывать дедлайны, задача сложная. Она становится ещё сложнее, если учесть, что нам приходится тестировать вёрстку. Это не два JSON сравнить: здесь не работают простые подходы «вызову функцию, проверю результат» — тестирование UI сложнее. Как эффективно и правильно тестировать верстку и писать для неё тесты, чтобы они были полезны, а дедлайны не горели, расскажет Максим Соснов (crazymax11), ведущий разработчик в СКБ Контур.
Пирамида тестирования
Если театр начинается с вешалки, то тестирование начинается с пирамиды тестирования.
Пирамида – это концепция, которая говорит, что в проекте есть 3 вида тестирования:
Чем выше тесты на пирамиде, тем они ценнее — они дают больше уверенности в том, что приложение работает так, как ожидается. Но при этом их дороже писать и поддерживать. Чем ближе тесты к основанию пирамиды, тем быстрее эти тесты написать и тем быстрее они исполняются.
Пирамида тестирования говорит, что тесты на проекте должны быть в следующей пропорции: много Unit-тестов, меньше интеграционных, и совсем чуть-чуть E2E-тестов.
Применим пирамиду тестирования
Посмотрим, как это работает — проверим пирамиду на небольшой функциональности, например, на простом поиске. У нас есть input для ввода пользовательского запроса и кнопка «Найти», которая отправляет запрос на бекенд.
Для реализации подобного функционала поделим приложение на стандартные, для фронтенд-архитектуры, слои:
Напишем тесты на это приложение на разных уровнях пирамиды тестирования. Возьмем типичный сценарий: пользователь заходит на сайт, набирает поисковый запрос, нажимает кнопку «Найти», а мы ему показываем результаты поиска.
Unit-тесты
Чтобы покрыть наш сценарий юнит-тестами напишем пять тестов.
Они не проверяют реальное взаимодействие между модулями. По тестам все может быть хорошо, но вместе модули могут и не работать. Мы узнаем об этом только после запуска кода на продакшн.
Тесты позволяют безопасно рефакторить только внутри модуля. Если поменять публичное API, например, Service, то также придется менять тесты на Store.
Тесты эмулируют DOM и HTTP. На основе таких тестов нельзя быть уверенным, что компонент действительно правильно отрендерится в браузере, и что наш сервис умеет работать с сетью.
Интеграционные тесты
Для сценария достаточно только одного интеграционного теста — нам не нужно больше тестировать модули в отдельности. При этом мы протестируем реальное взаимодействие между модулями, и будем уверены, что они умеют работать друг с другом.
Рефакторинг почти свободен. Если захотим как-то перекомпозировать наш код, например, по другому поделить ответственность в коде Store, это можно сделать не поменяв ни строчки теста.
Интеграционные тесты также эмулируют DOM и HTTP-взаимодействие. Мы не можем быть уверены, что компонент действительно рендерится в браузере и сервис правильно работает с сетью.
E2E-тесты
E2E-тесты похожи на интеграционные, но они выполняются реальном браузере. Обычно в проектах фронтенд пишется отдельно от бэкенда, поэтому мы также продолжим эмулировать API.
Сравнение
Если смотреть по зеленым ячейкам, то выглядит так, будто лучше всего писать интеграционные тесты, а Unit-тесты определенно хуже интеграционных тестов. Но пирамида тестирования требует писать очень много Unit-тестов. Неужели пирамида тестирования не работает?
Классическая пирамида тестирования работает, но не всегда. Её нужно правильно адаптировать к контексту. Также у пирамиды есть проблема с терминологией. Разные люди по-разному понимают термины Unit и E2E. Это часто приводит к холиварам в онлайн-чатах и в оффлайн обсуждениях: у кого-то тесты недостаточно E2E, или Unit’ы — не Unit’ы.
Большинство классических подходов отлично подходят для бэкенд-разработки, но для фронтенда их надо адаптировать. Но как?
Пирамида фронтенд-тестирования
Для фронтенда Kent C. Dodds вывел отдельную пирамиду тестирования, которую назвал «Трофей тестирования».
Вместо пирамиды у нас есть трофей.
Универсальная формула тестирования
Польза тестов прямо пропорциональна уверенности в работе кода после запуска тестов и обратно пропорциональна сумме стоимости написания, запуска и поддержки тестов.
Универсальная формула тестирования.
Но у этой формулы есть одна большая проблема — субъективность.
Искусство написания тестов заключается в том, чтобы правильно скомбинировать разные виды тестирования для нанесения максимальной пользы проекту.
Звучит слишком по-философски. Давайте разберемся, как это применять.
Инструменты во фронтенде
Давайте посмотрим, какие инструменты для тестирования есть во фронтенде.
На картинке представлены не все инструменты: только популярные и те, у которых есть логотипы.
И столько же подходов к тестированию.
Вариантов, как тестировать фронтенд-проекты, много. Я расскажу о двух видах тестирования, которые применяю в своих проектах. Они дают много уверенности в работе кода, но при этом требуют минимальных усилий, с точки зрения написания, поддержки и запуска тестов. Это скриншот-тесты через Storybook и функциональные тесты компонентов.
Скриншот-тесты через Storybook
Storybook позволяет разрабатывать компоненты в изолированной песочнице и поставлять им разные входные данные.
Добавим Storybook в наш проект с компонентом поиска — напишем простую команду:
Команда сама добавит Storybook в проект, сама настроит все конфиги и Storybook будет готов к запуску. Запускаем:
Storybook дословно это «Книга историй». В рамках storybook мы пишем истории для всех наших компонентов. Истории – это обычные функции, которые возвращают верстку.
Для нашего компонента поиска целесообразно описать три истории:
Теперь, если запустить Storybook, увидим следующую картину.
Слева в интерфейсе Storybook находится навигация по историям, а справа то, как выглядят компоненты. Компоненты кликабельны и даже доступны для редактирования, если поставить соответствующие дополнения.
Истории в Storybook:
Получается что истории в Storybook — это идеальная основа для скриншот-тестов. Существует множество решений для автоматизации использования историй как скриншот-тестов (а также есть возможность написать свой велосипед, но не делайте так — это намного сложнее, чем кажется). Из бесплатных вариантов рассмотрим два инструмента, с которыми у меня положительный опыт использования — Loki.js и Creevey.
Loki.js
Принцип работы Loki.js очень прост — он делает скриншот каждой истории с помощью Puppeteer, а затем попиксельно сравнивает получившиеся скриншоты с эталонными.
Открываем консоль и ставим Loki.js как зависимость:
Loki.js сам интегрируется в проект и сам все настроит для своей работы.
После этого запускаем Storybook.
Запустим Loki.js и посмотрим, как он делает скриншот-тесты. Открываем вторую консоль при открытом Storybook и пишем:
Работа с Loki.js. Попробуем что-то изменить в нашем компоненте, например, уберем Material UI кнопку и поставим нативную HTML-кнопку. Снова запустим.
Loki.js отмечает розовым разницу между двумя скриншотами. Не идеально, но помогает увидеть отличия.
Минус Loki.js. Он работает только в Chrome. Мы его быстро настроили, он хорошо работает в Docker, делает скриншоты, но, к сожалению, только в Chrome. Поэтому если вам нужно поддерживать IE11, попробуйте Creevey.
Creevey
Creevey — это молодой, но интересный проект, который разрабатывает Kiichiro. Проект находится в стадии активной разработки и его API может меняться.
Creevey использует Selenium, поэтому поддерживает практически все браузеры, в том числе и мобильные. Но, как следствие, для больших проектов придется поднять Selenium Grid. Кроме того, что Creevey делает скриншоты, он позволяет писать тесты прямо в Storybook рядом с историями.
Как работает. Добавим истории немного метаинформации для Creevey.
Здесь можно писать сценарий тестирования, например, попросить браузер кликнуть какой-нибудь элемент и только после этого сделать скриншот.
Как это выглядит в реальной жизни? Запускаем Creevey (и Storybook заодно). Интерфейс (похожий на Storybook) позволяет выбрать компоненты для тестирования, браузеры и тест-кейсы. Нажимаем кнопку «СТАРТ»: Creevey быстро делает скриншоты всех выбранных тест-кейсов и показывает их в своем интерфейсе.
Creevey показывает изменения. Например, если мы поменяли текст истории, Creevey покажет слева компонент до, справа – после изменений, а посередине сами изменения.
Изменения удобнее изучать, чем в Loki.js. В Creevey есть несколько режимов просмотра: не только как в Loki.js, но и в SWAP-режиме, когда окна просмотра переключаются в слайдовый режим, когда есть шторка, которую можно двигать.
Платные инструменты автоматизации
Кроме Loki.js и Creevey есть платные инструменты, например, Percy, Chromatic, Happo, которые поддерживают всё многообразие браузеров.
Платные инструменты просты в настройке и использовании. С Loki.js и Creevey нужно что-то делать в конфигах, уметь работать в консоли, желательно уметь настраивать Docker и Selenium Grid. Платные инструменты этого не требуют. Это просто Plug and Play – поставил и запустил.
В платных инструментах удобнее смотреть изменения. В Loki.js и Creevey мы много работаем в консоли — это может быть неудобно для не-разработчиков. Например, в Chromatic, это выглядит так.
Все видно наглядно. В сервис может зайти дизайнер и посмотреть изменения в компонентах в своей ветке, а затем подтвердить или отклонить. После этого в CI-систему, например, в GitHub вам в pull request придет подтверждение. Это, конечно, намного удобнее, чем Loki.js и Creevey.
Доступны по цене. При этом у этих инструментов есть бесплатные тарифы для Open Source и достаточно дешевые платные тарифы, которые начинаются от 30$ в месяц.
Функциональные тесты
Скриншот-тесты хорошо работают. Но они покрывают только статичные сценарии. А нам интересно протестировать весь сценарий, когда пользователь зашел, ввёл текст, кликнул на кнопки «НАЙТИ», подождал и получил результаты. Скриншот-тесты так не могут. Для этого, вместе со скриншот-тестами, нужно писать функциональные тесты.
Пример функционального теста
Функциональный тест похож на интеграционный тест в классическом понимании — мы тестируем всю фичу целиком, но при этом не используем реальный браузер и реальные запросы.
Настраиваем мок. Начнём тест с настройки сети.
В первой строке кода создаем spy. Spy – функция, которая запоминает все свои вызовы. В этом spy мы будем сохранять запросы к API поиска. Во второй строке настраиваем axios-mock-adapter: говорим ему, что в рамках теста придет запрос на /api/v1/search, на который нужно ответить 200 кодом и определенными данными. При этом нужно сохранить параметры запроса в spy.
Рендерим компонент. После настройки сети мы отрендерим компонент через testing-library. Через него же заполняем input поисковым запросом и кликаем на кнопку «НАЙТИ». После этого ждем, когда все перерендерится.
Теперь проверим был ли вызван поиск с тем текстом, который мы вводили с помощью testing-library и отобразил ли компонент результаты поиска в DOM-дереве.
Вот мы и написали функциональный тест. У него можно выделить следующие фазы:
Плюсы и минусы
Это полноценный тест на UI. Он проверяет, что продукт работает: если ввести текст в input и нажать кнопку «Найти», то приложение сделает запрос в API и выведет результаты поиска в интерфейсе.
С этим тестом можно рефакторить почти всё. Например, перенести логику из Store в компонент (или обратно), или заменить Redux на MobX.
Мы написали тесты без UI.
Немного комичный, но правдивый факт.
Но с этим тестом всё не так гладко.
Сценарий простейший, а в тесте просто так не разобраться — он большой и непонятный. Неподготовленные разработчики обязательно запутаются в коде.
Мы покрыли только позитивный сценарий, а у нас есть и другие. Например, API может ответить ошибкой 400, 500 или 404. Для каждого случая должна быть своя реакция приложения.
Подход плохо масштабируется. Когда мы будем описывать ещё сценарии, нам скорее всего придется писать очень похожий код. А если писать много похожего кода — то его будет сложнее читать… Поэтому хорошая и очевидная мысль – вынести код, который точно будет повторяться в большинстве тестов
Повторяющийся код
Мы точно знаем, что в каждом тесте будем запрашивать сеть. Почему бы не вынести настройку мока запроса в отдельную функцию?
Код с сетевым запросом мы вынесем в объект, который назовем ApiMock.
Бонусом добавим для pageObject ещё один метод, который позволяет получить из верстки результаты поиска.
Отрефакторенные тесты
Теперь тест занимает гораздо меньше места, при этом читается совершенно по-другому.
Если раньше тест читался очень низкоуровнево — настраиваем API, проставляем HTTP-код ответа, взаимодействуем с input, то теперь выглядит так:
Тесты теперь высокоуровневые. Они описывают не работу кода, а сценарий пользователя.
pageObject — это проверенный временем паттерн автоматического тестирования, популяризированный Selenium. Он позволяет вынести данные о странице из теста. Только PageObject знает об имплементации страницы: из каких элементов состоит страница, какие взаимодействия возможны с данной страницей, какие данные можно посмотреть на странице.
Ещё раз взглянем на отрефакторенные тесты — прочтем сверху вниз.
Здесь нет ни слова об используемых инструментах и библиотеках. В этом тесте нет ничего ни об axios-mock-adapter, ни о testing-library или React. В коде теста участвует jest, но его несложно заменит на mocha + chai.
Подход с функциональными тестами работает с любыми инструментами.
А это значит, что если бы мы писали честный E2E-тест с использованием cypress, puppeteer или Selenium, то тест остался бы примерно таким же. Подход написания функциональных тестов с PageObject’ами гибок и отлично масштабируется.
Как в итоге тестировать
На Frontend Live 2020 мы уделим тестированию отдельный трек. Это 2 дня полного погружения в тематику: доклады, мастер-классы, панельные дискуссии со спикерами и участниками. Обсудим, как обстоят дела с тестированием сейчас, какие наметились тренды, кому и чего не хватает, где взять знания, навыки и инструменты. И конечно, участники получат карту и пирамиду тестирования фронтенда с типами тестирования и применяемыми технологиями.
Бронируйте билеты — 14 сентября повышение цены. Подписывайтесь на рассылку, в которой присылаем новости, анонсы и промокоды:)