Что такое E2E тестирование? Разбираемся с определениями и подбираем инструментарий.
Тестирование является неотъемлемой частью процесса разработки веб-приложения. Приняв как должное необходимость покрытия системы модульными и интеграционными тестами, зачастую может встать вопрос о необходимости добавления End-to-End тестирования, с помощью которого можно проверить правильность работы основных бизнес-сценариев веб-приложения и убедиться в том , что приложение работает корректно для конечного пользователя.
Понятие е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 тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими — зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.