Home

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я упоминала, что специально использую UI, дабы обозначить, что он должен находиться на вершине тест-пирамиды, в то время как в других случаях вершина называется E2E. Чувствую, надо подробнее это объяснить.

UI – это пользовательский интерфейс. UI-тестирование относится к тестированию, выполняемому через UI.

E2E – это end-to-end тестирование. Это тесты, которые выполняются от входной точки в приложения до выхода из него.

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

Однако они отличаются важными нюансами.

В идеале тесты на вершине тест-пирамиды должны проверять end-to-end поведение, максимально близкое к поведению реального пользователя. Это также называют «пользовательским путем».

С другой стороны, UI-тесты склонны больше концентрироваться на внешнем виде конечного продукта и ощущениях от него. Как правило, в этих тестах можно встретить визуальную валидацию (ручную или автоматизированную) и валидацию CSS. И тут все немного усложняется…

Так как для тестирования UI нам нужно, чтобы он был готов, мы проводим UI-тесты в рамках E2E-тестирования, на вершине тест-пирамиды. Однако местоположение на вершине означает, что этих тестов должно быть меньше, чем тестов на других уровнях.

Верное количество UI-тестов

Одна из хороших практик тестирования – это небольшие независимые тесты; в этом случае в проблемах легче разобраться, и не потребуется множества прогонов, чтобы добыть всю необходимую информацию (кейсы склонны падать, наткнувшись на первую же ошибку, и дальше не продолжать). В то же самое время на верху пирамиды мы хотим видеть минимально возможное количество тестов. Как добиться обеих этих целей?

Визуальные валидации и сравнения CSS обычно проводятся в рамках E2E, но если делать эти тесты атомарными, мы рискуем изменить пропорции тест-пирамиды. К счастью, сейчас существуют инструменты визуальной валидации, выдающие все найденные ошибки оптом в одной-единственной проверке.

Есть также способы продолжать прогон, даже если произошло падение. Посмотрите, возможно ли это в вашем инструменте – чтобы тест, скажем, проверял, как выглядит и работает страница Х, и внутри теста мы могли получить все найденные проблемы оптом.

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

Динамическое содержимое

Вышеупомянутые тесты могут сработать для статичного сайта, но мы, как правило, сталкиваемся с динамическим содержимым. В этих случаях сравнение скриншотов не поможет поддерживать тесты атомарными – понадобятся разные скриншоты.

Иногда нам нужно совершить какое-то действие перед появлением содержимого. К примеру, если вы нажимаете кнопку, появляется список – мы, возможно, захотим проверить, что список содержит верные данные. Но содержимое этого списка для любой комбинации вариантов уже должно быть покрыто интеграционными тестами – в E2E достаточно убедиться, что список на месте.

Что будет, если неверна пагинация, или список не влезает в свое место при определенном разрешении, или за результаты отвечает какая-то другая часть UI? Это резонные опасения, об этом в ходе интеграционного тестирования мы знать не можем – это потребует расширения покрытия, увеличения количества проверок, а следовательно, большего количества тестов.

Более того, такие тесты очень тяжело поддерживать. Тут надо подойти креативно, находя или создавая инструменты, позволяющие добиться большего при меньших затратах.

Команды фронтенда

Иногда может показаться, что юнит-тестами можно пренебречь – все то же самое мы покрываем уровнем выше. Да, это возможно, но будет дороже, труднее в поддержке, дольше в запуске… И именно поэтому тест-пирамида не рекомендует так делать.

Это часто встречается среди разработчиков, которые предпочитают не имитировать соединения и проводят юнит-тесты в рамках интеграционных тестов. Тут как минимум есть проблема с меньшим уровнем детализации интеграционных тестов. К тому же размышления о юнит-тестах могут помочь разработчикам изначально писать код лучше.

Другой распространенный случай – разделение команд на команды бэка и команды фронта. В этом случае они не участвуют в интеграционных тестах полученных фич.

Ряд фич может эксклюзивно принадлежать фронту – например, изменение внешнего вида и работы кнопки. Значит ли это, что здесь не нужно интеграционное тестирование? Как правило, нужно.

Интеграционные тесты фронтенда

Представим ситуацию, что кнопка меняет внешний вид. Бэк не менялся, поэтому интеграционные тесты бэка отсутствуют.

С шансами, работая на фронте, вы имеете дело с виджетом, сторибуком или чем-то подобным. Это части сайта, которые в какой-то момент соединятся воедино. Их тестирование требует запуска фичи в определенном окружении, а также запуска и работы браузера. Это уже можно считать интеграционными тестами – для выполнения верификаций нужно несколько компонентов, даже если вы верифицируете UI.

Иногда эти тесты никуда не заносятся и могут даже проводиться вручную, и в результате создается ложное чувство, что их не существует.

Чтобы протестировать это с точки зрения E2E, понадобится довести до рабочего запущенного состояния все приложение; все виджеты уже должны быть скомбинированы и соединены, и настройка всего этого богатства для проведения теста встанет значительно дороже.

Если кнопка также создает новую функциональность, то будут еще и API-вызовы (требующие интеграционного тестирования), а проверки UI могут быть частью общих UI-проверок. Может создаваться новый пользовательский путь, но он, как правило, потребует меньше проверок, чем интеграционный тест.

Все ситуации уникальны

Как можно видеть, детали зависят от конкретного случая, и решения надо принимать соответственно. Могу даже представить себе странный сценарий, когда интеграционные тесты равны E2E-тестам по количеству.

Рассматривайте тест-пирамиду как общие указания для более быстрого и качественного тестирования, а не как выбитое в камне правило. В конце концов, вам нужно заниматься тем, что несет больше смысла и наилучшим образом покрывает приложение, балансирует качество и скорость разработки, и учитывает издержки.

Однако не стоит забывать, что тест-пирамида существует не просто так – если мы потеряем бдительность, если между командами нет согласия, то мы начнем дублировать тесты, но это уже другая история.

Обсудить в форуме