Что такое e2e процесс
Учимся e2e-тестированию с Playwright | #30DaysOfPlaywright
День 0. Учимся e2e-тестированию с Playwright | #30DaysOfPlaywright
Этот цикл статей изначально задумывался как челлендж на 30 дней, проводимый с 1 по 30 декабря. Однако автор не успел подготовить 30 статей, потому они будут выходить постепенно. Весь список оригинальных материалов можно посмотреть тут, а я постараюсь переводить как можно быстрее.
В этом месяце было решено изучить тему, которая привлекает лично меня – e2e-тестирование веб-приложений. Я хочу перейти от изучения основных концепций и инструментов к реализации эффективных стратегий кросс-браузерного тестирования в рабочих процессах разработки веб-приложений. Планирую сделать это с помощью Playwright.
Присоединяйтесь к #30DaysOfPlaywright. Давайте изучим инструменты, API и лучшие практики, по одному сценарию тестирования за раз!
Что такое Playwright?
Playwright – это open source фреймворк для web-тестирования и автоматизации. Он позволяет осуществлять кросс-браузерное тестирование и web-автоматизацию через Chromium, Firefox и WebKit с единым API.
Хотите быстро познакомиться с Playwright и его концепциями?
Посмотрите 45-минутное «Введение в тестовую программу Playwright» от Андрея Лушникова из команды разработчиков фреймворка.
Зачем нужно кросс-браузерное тестирование?
Ключевое преимущество веб-приложений перед платформенным софтом – в их доступности. Пользователи могут получить доступ к приложению, просто перейдя по нужной ссылке (URL) из любого современного браузера на устройствах с различными форм-факторами (мобильное, десктопное, встроенное, ТВ) без дополнительных усилий.
Проблема заключается в том, что пользователи ожидают единообразного взаимодействия (пользовательского интерфейса и поведения продукта) на различных платформах и устройствах, пренебрегая различиями в их возможностях.
Кросс-браузерное тестирование гарантирует, что ваше приложение работает должным образом в любом из современных браузеров. Таким образом, созданный пользовательский интерфейс будет соответствовать ожиданиям пользователей. В рамках тестирования может проверяться производительность, доступность, скорость отклика и целостность данных. Все это на базе любых браузеров и операционных систем.
Зачем автоматизировать тестирование?
Как разработчики приложений, вы, вероятно, знакомы с написанием и выполнением модульных и интеграционных тестов вручную в рамках ваших рабочих процессов. Но при масштабировании тестовой стратегии становится трудно выполнять прогоны (например, в системе гораздо больше коммитов) или детализацию тестов (требуется проверка на большем количестве браузеров и платформ).
Веб-автоматизация или автоматическое тестирование – это процесс использования средств выполнения задач вместе с тестовыми инструментами. Так они задействуются для ускорения выполнения и автоматизации рабочих процессов в соответствии с необходимыми уровнями детализации и частотой тестирования. При этом обеспечивается достаточная надежность и эффективность.
Почему стоит выбирать Playwright?
Согласно документации, Playwright разработан, чтобы быть быстрым, надежным, практичным и всегда актуальным с итеративными обновлениями, сглаживающими кривую обучения.
С точки зрения разработки веб-приложений данный фреймворк имеет много полезных функций которые включают в себя:
встроенный тестовый раннер (Playwright Test) с обширным API;
использование Playwright как библиотеки, что позволяет подключать другие тест раннеры;
использование headless и headed режимов тестирования;
поддержку эмуляции устройств для проверки UX (user experiences) на мобильных устройствах.
В течение следующих 30 дней мы рассмотрим API Playwright, изучим инструменты и примеры, которые позволят использовать весь функционал фреймворка в контексте реального тестирования.
Важные ресурсы:
И не забывайте подписываться на @playwrightweb в Twitter, чтобы следить за обновлениями.
День 0: Обзор
✅ Посети перечисленные важные ресурсы.
✅ Посмотри и поставь звезду репозиторию Playwright
День 1: Начало работы с Playwright
Лучший способ чему-то научиться – это поработать с кодом. В следующей статье блога мы расскажем, как начать работу с Playwright. По итогам импровизированного “занятия” вы должны:
установить тестовый раннер Playwright Test;
написать и выполнить свой первый тестовый скрипт;
изучить режимы headless и headed для тестирования;
изучить основные параметры конфигурации;
использовать фундаментальные концепции, такие как assertions, fixtures и test hooks;
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 для организации централизованных миграций и обновления системы микросервисов.
Как мне указали в комментариях, тема не раскрыта.
Попытаюсь указать здесь наиболее спорные тезисы.
Сквозное тестирование (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 тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими – зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.
Джеймс Славет: Что такое Е2Е бизнес?
Термины B2C и B2B появились фактически вместе с интернетом. Но в последние годы возникло новое предпринимательское движение, которое сейчас резко пошло в гору. Я называю его Е2Е, то есть «end to end». Компании E2E сосредоточены на интересах конечных пользователей: с помощью самого современного софта они объединяют людей, которые хотят получить или предоставить различные услуги. Это очень удобный онлайновый сервис для реального, оффлайнового мира.
Всегда считалось, что фундаментальным качеством идеального стартапа в Силиконовой долине является способность к быстрому, масштабному росту. Команда из 10 человек создала продукт для 10 миллионов? Вот это то, что надо. Но иногда наступают времена, когда требуются проекты, которые невозможно масштабировать, когда старомодное человеческое внимание к интересам конкретного клиента превращается в ключевой элемент общего уравнения. Качество обслуживания становится столь же важным как качество кода. Алгоритмы могут устареть, срок патента закончится, но репутация компании с качественным сервисом никуда не денется.
Е2Е меняет сферу услуг
Сфера услуг – это главный двигатель нашей экономики. И этот сектор ожидает существенная трансформация под воздействием растущих компаний Е2Е. Лучшие из них (как правило, это новички, которые были задуманы как Е2Е бизнес с самого начала) станут ключевыми брендами для следующего поколения потребителей.
Особая система контроля за качеством работы агентов помогает Redfin создать уникальное предложение на рынке. Например. У всех агентов Redfin есть рейтинги, которые им присваивают клиенты. Эти рейтинги любой может увидеть на сайте агентства. И размер дохода агентов зависит именно от этих рейтингов, а не суммы сделок.
Все агенты имеют доступ к специальному программному обеспечению, которое помогает им правильно подобрать недвижимость, а также наиболее точно определить цену покупки или продажи. Сейчас Redfin инвестирует деньги в новый софт и создает систему логистики на местах, что позволит организовать «мгновенные просмотры», так что заказ просмотра квартиры или дома станет таким же простым делом как заказ такси.
Другие ведущие Е2Е компании, например, Airbnb и Über, работают по принципу онлайн-рынков (marketplace business models). Они не нанимают поставщиков услуг и, тем не менее, расходуют значительные средства на улучшение качества обслуживания, стремясь сделать его самым лучшим. Airbnb предлагает бесплатные услуги профессиональных фотографов тем, кто хочет сдать с помощью компании свою квартиру, а работу ее круглосуточной горячей линии обеспечивает разветвленная сеть агентов по всем миру. Именно инвестиции в качество обслуживания стали основой успеха Airbnb. «Если бы я делал все заново, я бы не давал компании расти так быстро», – признался однажды СЕО и со-основатель Airbnb Брайн Чески.
Другие крупные сегменты сферы услуг – образование, здравоохранение, финансы – также существенно преобразятся под воздействием Е2Е движения. Например, вместо того чтобы сидеть в обшарпанном зале какого-нибудь местного дома культуры на лекции второсортного профессора, вы можете включить iPad и попасть в интерактивный класс к одним из лучших в мире преподавателей.
Или, например. В два часа ночи вашему трехлетнему ребенку стало плохо. Вместо того чтобы в панике нестись в больницу, вы можете включить компьютер и получить быструю онлайн-консультацию у хорошего врача.
И, наконец, если вы не хотите сами заниматься инвестированием своих денег, но точно также не хотите платить каждый год 1% от стоимости своих активов какому-то дяде просто за то, чтобы он иногда приглашал вас поиграть в гольф, тогда вот вам отличное и недорогое Е2Е решение этой проблемы.
Почему Е2Е компании вдруг начали расти?
Интернет существует уже давно, а сфера услуг еще дольше. Но почему именно сейчас Е2Е бизнес начал так бурно развиваться?
Во-вторых, многие из лучших предпринимателей последнего десятилетия – Джобс, Безос, Брэнсон, Маск – не ограничивали себя созданием веб-сайтов и написанием мобильных приложений. Они построили великие компании, ориентированные на потребности клиентов в реальном мире, и именно их деятельность служит источником вдохновения для нового поколения предпринимателей.
Взгляд инвестора на E2E
Компании E2E не привлекут сотни миллионов пользователей всего за пару-тройку лет как Youtube, Instagram или Snapchat. И вряд ли в ближайшем будущем их захотят купить Google, Facebook или Twitter. Когда на недавней встрече с инвесторами гендиректора Redfin Гленна Келмана спросили, кто, по его мнению, является наиболее логичным покупателем его бизнеса, он задумался, улыбнулся и сказал: «Никого у нас пока нет». Компании E2E – это не для всех.
И всё же лучшие из E2E компаний имеют невероятный потенциал стоимости для клиентов, персонала и акционеров. Ими будут руководить харизматичные СЕО. Они будут атаковать устоявшиеся, крупные рынки. Они будут сосредоточены на качестве обслуживания. Они будут великолепно управляться. Их будет невозможно остановить. И они будут расти, расти и расти.
Автор – Джеймс Славет, партнер венчурной фирмы Greylock Partners, которая является инвестором компаний Airbnb и Redfin
Про пользу 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 тесты?