E2E тестирование Web-приложений

Муравьева Мария

Автоматизированное тестирование

​

Почему автоматизированное тестирование так востребовано?

• Программные продукты регулярно обновляются (Agile, частые релизы);
• АТ часто окупает затраты на внедрение, особенно на больших проектах;
• Позволяет “отлавливать” критические ошибки на ранних этапах изменений в коде приложения;
• Позволяет проверять работу кода на нескольких уровнях (уровне модуля, уровне системы, полностью рабочее приложение);

Пирамида тестирования

• Unit-тесты - проверяют работу отдельного компонента системы (юнита);

​

• Integration-тесты - проверяют работу нескольких компонентов системы (либо работу компонента системы и внешних компонентов (БД, сторонних сервисов).

​

• E2E - проверка работы всего приложения от начала до конца (с перспективы конечного пользователя).

E2E и UI тесты: в чем разница?

• UI тестами можно назвать любые тесты пользовательского интерфейса. Например, юнит-тесты для React можно считать UI тестами, хотя E2E они не являются.
• E2E (end-to-end) тесты тестируют всю систему от начала до конца при выполнение какого-то конкретного сценария. Часто, особенно в случае Web-приложений это выполняется через манипуляции с GUI, но есть исключения (например, API-сервисы).

E2E для Web-приложений

• REST API (GraphQL) тестирование - пишем запросы к API и проверяем, что все выполняется без ошибок и возвращает корректные результаты;
• UI E2E-тесты - симулируем действия пользователя с пользовательским интерфейсом на развернутом (локально или удаленно) приложении, и проверяем, что пользователь видит ожидаемый результат.
• Selenium Webdriver
• Cypress
• Puppeteer (больше сфокусирован на Chromium)

REST API тестирование

Пример кода смотрите здесь.

UI Automation Тесты

• Имитируют взаимодействие реального пользователя с браузером;
• Используют селекторы для доступа к конкретным HTML-элементам приложения;
• Менее стабильны в сравнении с другими видами тестов;
• Прохождение может занимать много времени;

Selenium Webdriver

• Является основой для множества GUI-testing фреймворков:
• Protractor;
• Nightwatch;
• Galen;
• Требует специальное приложение: Webdriver, к которому отправляет команды по удаленному Selenium API;
• Кроссплатформенный, кроссбраузерный и кроссязычный (Java, C#, Javascript, Kotlin, Python);
• Поддерживает разные виды селекторов (ID, Name, XPath, селекторы CSS, текстовые ссылки, текстовые частичные ссылки);
• Не имеет встроенных Dashboard инструментов, но позволяет интегрироваться с такими решениями как Extent, Allure;
• Позволяет настроить параллельное выполнение тестов (Selenium Grid).

Пример

Cypress

• Кроссплатформенный и кроссбраузерный;
• Поддерживает только Javascript;
• Не требует отдельного приложения для запуска, работает в браузере;
• Встроенный Dashboard;
• Позволяет отследить выполнение тестов и состояние каждого шага с помощью снэпшотов;
• Позволяет перехватывать и переопределять запросы от сервера;
• Поддерживает только CSS и XPath селекторы;
• Имеет ограничения в интеграции с CI/CD.

Пример

Cucumber и Gherkin

• Cucumber - инструмент, позволяющий реализовать парадигму BDD (behavior driven-programming):
• Тесты разделяются на две части:
• Описание сценария на Gherkin (язык, близкий к человеческому)
• Описание отдельных шагов на языке программирования (Java, Javascript, C#)
• Шаги могут переиспользоваться;
• Сценарии могут читать/писать люди, незнакомые с языками программирования вообще (Product менеджеры, тестировщики)

Пример.

Page Object Pattern

Суть:

• Элементы страницы и ее поведение инкапсулируется в специальном классе;
• Тестовый код взаимодействует со страницей не через прямые вызовы к WebDriver, а через строго определенный интерфейс;

Преимущества:

• Четкое разделение между тестовым кодом и методами Selenium.
• Все операции над страницей сконцентрированы в одном месте, что обеспечивает выполнение Single Responsibility принципа;

Также можно продолжить эту идею и использовать Page Component Objects - логически сгруппированные элементы UI, которые представляют собой отдельные фрагменты страницы, доступ к которым также можно реализовать через интерфейс, скрывающий внутреннюю логику.

Request interception

Идея: перехватываем трафик сети (например, REST запрос к API) и подменяем ответ нужными нам данными.

Преимущества: можем обеспечить стабильное состояние системы, сделать “заглушки” для сторонних сервисов.

Недостатки: тесты перестают быть полностью end-to-end, придется подменять запросы для всех связанных запросов, чтобы обеспечить консистентность работы приложения.

Заполнение БД данными и изолированность тестов

• Перед запуском тестов нужно убедиться, что приложение находится в “чистом” состоянии (БД должна быть очищена и заполнена тестовыми данными);
• В идеале желательно, чтобы после каждого запущенного тестового сценария изменения в БД сбрасывались;
• Заполнение БД данными можно осуществлять как через БД, так и через API.

Полезные ссылки

1. https://martinfowler.com/articles/practical-test-pyramid.html#UiTests - статья про пирамиду тестирования с практическими примерами.
2. https://www.selenium.dev/ - Selenium
3. https://www.cypress.io/ - Cypress
4. https://www.selenium.dev/documentation/guidelines/page_object_models/ - паттерн PageObject
5. https://cucumber.io/ - Cucumber и Gherkin
6. https://github.com/maria-muravyova/e2e-lecture - исходный код с примерами

The End(-2-end)