Что такое пирамида тестирования
От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте
О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали на Хабре. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (Kristin Jackvony), где графически показан еще один метод – колесо автоматизации.
Автоматизация тестирования, как правило, наиболее необходима в масштабных приложениях с большим количеством бизнес-функций, при внедрении CI/CD и регулярных релизов. Подробнее об этом мы рассказывали в статье «Что даёт автоматизация тестирования».
С разрешения Кристин Джеквони – автора блога Think Like a Tester и ряда популярных материалов о тестировании – мы перевели статью «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel). В конце статьи рассмотрим пример проверок из практики наших специалистов по автоматизации тестирования (SDET).
Каждый, кто занимался автотестами, слышал о Пирамиде автотестов. Обычно она имеет три слоя: тесты UI, API и Unit. Нижний слой, самый широкий, занимают Unit-тесты – это означает, что таких тестов должно быть больше, чем прочих. Средний слой – это API-тесты; идея в том, что их нужно запускать меньше, чем Unit-тестов. Наконец, верхний слой – это UI-тесты. Их должно быть меньше, чем остальных, т.к. они требуют больше времени на прохождение. Кроме того, UI-тесты наиболее нестабильные.
Пример пирамиды автотестов на Хабре. Метод описан в книге Майка Кона «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).
С моей точки зрения, в этой пирамиде две проблемы:
Я предлагаю другой подход к автоматизированному тестированию – Колесо автоматизации.
Каждый из типов тестов можно рассматривать как спицу в колесе. Нет спицы, которая была бы важнее других – они все необходимы. Размер сектора колеса не означает число тестов, которые должны быть автоматизированы. При этом нужно предусмотреть проверки по каждому указанному направлению, если в вашем проекте требуется обеспечивать качество в соответствующей области.
Unit-тесты (Unit Tests)
Unit-тесты – это самые маленькие автотесты, какие только возможны. Они проверяют поведение только одной функции или одного метода. Например, есть метод, который проверяет, равно ли число 0, тогда можно написать такие Unit-тесты:
Компонентные тесты (Component Tests)
Эти тесты проверяют разные сервисы, от которых зависит код. Например, если мы используем API GitHub, то можно написать компонентный тест для проверки того, что запрос на данный API получает ожидаемый ответ. Или это может быть просто пинг до сервера, проверка доступности базы данных. Должен быть хотя бы один компонентный тест на каждую используемую в коде службу.
Примечание: например, у нас в SimbirSoft к компонентным тестам, помимо проверки ответов сторонних сервисов, относятся проверки модулей одной системы, если её архитектура представляет собой набор таковых.
Сервисные тесты (Services Tests)
Такие тесты проверяют доступность веб-сервисов, к которым обращается приложение. Чаще всего работа с ними организована через использование API запросов.
Например, для API с типами запросов POST, GET, PUT и DELETE мы можем написать автотесты на проверку каждого типа запросов. Причем наши тесты будут проверять как позитивные, так и негативные типы сценариев, при которых некорректный запрос возвращает соответствующий код ошибки.
Тесты пользовательского интерфейса (User Interface Tests, UI Tests)
UI-тесты проверяют правильность реакции системы на действия конечного пользователя. К таким проверкам относятся, например, тесты, проверяющие ответ системы на заполнение текстовых полей или на нажатие кнопок.
Как правило, любая функциональность системы, которая может быть протестирована с помощью Unit, компонентного или сервисного теста, должна быть проверена с использованием упомянутого типа теста. Тесты же пользовательского интерфейса должны быть сосредоточены исключительно на выявлении ошибок во взаимодействии пользователя с графическим интерфейсом.
Визуальные тесты (Visual Tests)
Визуальные тесты проверяют отображение элементов интерфейса на экране. Они схожи с UI-тестами, но фокусируются на проверке внешнего вида интерфейса, а не на функциональности. Примерами таких проверок могут быть проверка правильности отображения изображения кнопки или проверка отображения логотипа продукта на экране.
Тесты безопасности (Security Tests)
Это тесты, проверяющие соблюдение мер безопасности и защиты данных. Они по механике похожи на сервисные тесты, но тем не менее рассматривать их следует отдельно. Например, тест безопасности может проверить, что токен авторизации не будет создан при недопустимой комбинации логина и пароля. Другой пример – создание GET-запроса с токеном авторизации для пользователя, не имеющего доступа к этому ресурсу, и проверка того, что будет возвращен ответ с 403 кодом.
Примечание: с сервисными тестами эти проверки роднит только способ вызова служб – через http-запросы. Цель таких тестов – исключительно в проверке защищенности системы и пользовательских данных от действий злоумышленника.
Тесты производительности (Performance Tests)
Автотесты производительности проверяют, что ответ на запрос приходит в рамках соответствующего периода времени. Например, если есть требование к системе, что GET-запрос никогда не должен занимать дольше двух секунд, то при превышении этого ограничения автотест вернет ошибку. Время загрузки web-интерфейса также можно измерять с помощью тестов производительности.
Тесты доступности (Accessibility Tests)
Автотесты проверки доступности служат для проверки самых разных вещей. В сочетании с тестами пользовательского интерфейса они, например, могут проверять наличие текстового описания изображения для слабовидящих. В рамках проверки доступности визуальные тесты могут быть использованы для проверки размера текста на экране.
Как выбрать методы проверки
Возможно, вы заметили, что приведенные выше описания тестов часто пересекаются друг с другом. Например, тесты безопасности могут выполняться в процессе тестирования API (сервисные тесты), а визуальные тесты – в процессе тестирования пользовательского интерфейса. Здесь важно, чтобы каждая область была проверена тщательно, эффективно и точно.
После выхода статьи «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel) вышел список факторов, помогающих определить необходимую долю тестов каждого типа в колесе автоматизации:
Из практики SimbirSoft
Мы считаем, что колесо автоматизации – полезный способ визуализации типов тестирования. Безусловно, мы давно используем описанные тесты, но картинка помогает проанализировать покрытие системы и держать всё перед глазами.
Если у вас отлажен процесс тестирования и вы регулярно прогоняете автотесты, это минимизирует риск попадания дефектов в продакшен. К тому же, автотесты помогают оперативно выявлять проблемы, которые могут возникнуть в процессе работы системы. Например, с помощью планового ежедневного прогона автотестов можно контролировать свой сайт, чтобы защитить себя от взломов.
Какие использовать проверки и в каком количестве – зависит и от требований, и от самой проверяемой системы. Так, в одном из наших продуктов – банковском мобильном приложении – по требованию клиента были подготовлены автотесты всех перечисленных ранее видов. Рассмотрим их примеры далее.
Unit Tests
Мы позаботились о том, чтобы каждая функция в коде приложения была покрыта тестами, проверяющими все возможные пути. При этом активно использовали моки, заменяющие собой другие части системы. Например, проверяя функцию конвертации рублей в валюту, мы подавали на вход функции поддерживаемые ей рубли, чтобы проверить, что на выходе получим валюту. Сравнение происходило с эталонными величинами. Также проверяли реакцию функции на невалидные данные.
Component Tests
Здесь мы проверяли компоненты мобильного банка. Так как у нас микросервисная архитектура, нужно было проверить доступность всех микросервисов, а также, как пример, доступность базы данных. Для сервиса, ответственного за расчетные счета клиента, мы выполняли запрос к базе данных для получения расчетного счета и проверки того, что счет может быть получен.
Services Tests
Мы проверяли API, через которое в предыдущем примере отправляются запросы к базе данных. Отправляли GET-запрос на получение номера расчетного счета и проверяли ответ на него. Обязательно отправляли какой-либо некорректный запрос, например, с несуществующим id клиента, и проверяли, что ответ соответствует ожидаемому.
UI Tests
Например, мы проверили корректную реакцию системы на заполнение полей счета, а также ответ системы на нажатие кнопки «Открыть вклад».
Visual Tests
Мы протестировали устройства с разными версиями iOS и Android и диагональю экрана и проверили расположение элементов приложения. Эта проверка была нужна, чтобы убедиться, что при любом сочетании этих параметров кнопки не наезжают на логотип и не скрываются за ним, становясь недоступными для нажатия.
Security Tests
Мобильный банк – финансовая система, поэтому его безопасность нужно было обеспечить на всех уровнях. В числе прочего мы проверяли аутентификацию только по правильным данным на уровне пользовательского интерфейса и получение информации только в ответ на запрос с корректным токеном на уровне сервисов.
Performance Tests
Одним из тестов было сравнение с эталоном времени ответа сервера на запрос приложения. Также мы проверили работу приложения при максимально ожидаемом количестве одновременно работающих пользователей в системе.
Accessibility Tests
Проверили голосовой поиск и отображение элементов разметки с активированным режимом для слабовидящих.
О том, как можно организовать автоматизацию тестирования с нуля, мы расскажем подробнее в одной из следующих статей.
Спасибо за внимание! Надеемся, что перевод был вам полезен.
Что такое пирамида тестирования
«Пирамида тестов» — абстракция, которая означает группировку тестов программного обеспечения по разным уровням детализации.
Она также даёт представление, сколько тестов должно быть в каждой из этих групп.
Из этой пирамиды главное запомнить два принципа:
Придерживайтесь формы пирамиды, чтобы придумать здоровый, быстрый и поддерживаемый набор тестов.
-Напишите много маленьких и быстрых юнит-тестов.
-Напишите несколько более общих тестов
— и совсем мало высокоуровневых сквозных тестов, которые проверяют приложение от начала до конца.
Подробнее о Классической пирамиде тестирования:
Модульные тесты должны составлять основную часть автоматизированного тестирования.
— Задачи автоматизации не закрываются до тех пор, пока эти скрипты не будут запущены на реализованной функциональности;
— Разработка одновременно с модульными тестами заставляет разработчиков задуматься о проблеме, которую они решают, и о любых крайних случаях, с которыми они могут столкнуться;
— Тесты являются детальными и могут помочь точно определить дефект;
— Время выполнения невероятно быстрое, потому что им не нужно полагаться на какой-либо пользовательский интерфейс или внешние системы, такие как база данных или API;
— Они недорогие, просто пишутся, легко поддерживать.
Интеграционные тесты должны занимать середину пирамиды.
Используйте этот уровень для проверки бизнес-логики без использования пользовательского интерфейса (UI);
Тестируя за пределами пользовательского интерфейса, вы можете тестировать входы и выходы API или сервисов без всех сложностей, которые вводит пользовательский интерфейс;
Эти тесты медленнее и сложнее, чем модульные тесты, потому что им может потребоваться доступ к базе данных или другим компонентам.
Тесты пользовательского интерфейса должны размещаться на вершине пирамиды.
Большая часть вашего кода и бизнес-логики должна быть уже протестирована до этого уровня;
Тесты интерфейса пишутся, чтобы убедиться, что сам интерфейс работает правильно;
Тесты пользовательского интерфейса медленнее и тяжелее в написании и поддержке, поэтому необходимо сводить их к минимуму.
Перевернутая пирамида тестирования или «Рожок мороженного»
Перевернутая пирамида считается не рекомендованной, хотя в практике такой подход встречается.
Основные тезисы:
1. Тесты пользовательского интерфейса должны автоматизироваться в большей мере.
2. Длинные тестовые прогоны. Время выполнения занимает намного больше времени, чем другие типы тестов, потому что оно основано на взаимодействии с визуальными элементами пользовательского интерфейса и не обязательно имеет хуки в исходном коде;
3. Сложно поддерживать, так как тесты пользовательского интерфейса сложно писать и они очень сильно зависят даже от малейших изменений;
4. Больше подходит для сценариев позитивного пути. Тестирование отрицательных путей в сквозных тестах очень затратно и долго выполняется по сравнению с тестами более низкого уровня;
5. Ожидание написания модульных тестов до тех пор, пока функции не будут завершены, может привести к тому, что каждому придется несколько раз выполнить большую работу для решения проблемы.
На интервью у Вас могут спросить, как будет выглядеть Фигура тестирования без разделения команд на frotnend и backend. Или как будет выглядеть Фигура тестирования на бэкенде. Данные вопросы скорее направлены на логику и понимание, ответ на них подразумевает размышление о структуре тестов на проекте.
Например: Front это конечно UI Test, а Back это Unit+Интеграционные+Системные. Значит получается Трапеция (или усеченная пирамида), без верха UI Test. Или пирамида на вершине которой API Test.
Как встроить качество в процессы производства ПО? (Часть 2)
В предыдущей статье Как встроить качество в процессы производства ПО? мы коснулись основных понятий про качество, четырехуровневый процесса управления и обеспечения качества, увидели что требования и качества тесно связаны друг с другом.
STLC и SDLC живут параллельно
Этап 1. Анализ требований. На данном этапе группа тестирования изучает требования с точки зрения тестирования, чтобы идентифицировать тестируемые требования, а группа QA может взаимодействовать с различными заинтересованными сторонами для детального понимания требований. Требования могут быть функциональными или нефункциональными. На этом этапе также выполняется технологическое и экономическое обоснование автоматизации тестирования.
Этап 3. Разработка тест кейсов. Этап разработки тест кейсов включает в себя создание, проверку и переработку тест кейсов и тестовых сценариев после того, как план тестирования будет готов. В первую очередь идентифицируются тестовые данные, затем создаются и проверяются, а затем переделываются на основе предварительных условий. Затем команда QA начинает процесс разработки тест кейсов для отдельных модулей.
Этап 4. Настройка тестовой среды. На данном этапе определяются программные и аппаратные условия, при которых продукт будет тестироваться. Это один из важнейших аспектов процесса тестирования, который может выполняться параллельно с этапом разработки тест кейсов.
Этап 5. Выполнение тестов. На этом этапе работают тестировщики, которое тестируют сборку программного обеспечения на основе подготовленных планов тестирования и тест кейсов.
SDLC и STLC работают параллельно и в этих процессах участвуют все и не только разработчики и тестировщики. Чтобы вся команда работала над встраиванием качества в процессы, в продукт, надо работать с мышлением и менять его. Команда должна понимать, что качественное тестирование очень важно для бизнеса, так как цена исправления пропущенных и обнаруженных ошибок на продуктивных средах может оказаться катастрофически высока (такие ошибки могут ударить не только по финансам, но и по репутации).
Относительная стоимость исправления ошибок в зависимости от времени и места обнаружения
Очень важен выбор типов тестирования. Существует как минимум 105 видов тестирования программного обеспечения. Но, естественно, все применять на продукте и в процессах не надо. Наоборот, список функциональных и не функциональных типов тестирования надо формировать обдуманно. Список должен включать в себя 4 категории тестов
Тесты, которые направляют разработку, заставляя команду разработчиков думать о том, как они будут тестировать story или фрагмент кода, прежде чем писать его.
Тесты ориентированные на бизнес и/или технологии. Написанные с использованием бизнес-терминологии, бизнес-тесты должны быть понятны пользователю. Написанные на языке разработчика, технологические тесты используются для оценки того, обеспечивает ли система поведение, задуманное разработчиком.
Тесты критикующие решение путем оценки системы на соответствие требованиям пользователя, чтобы найти дефекты или отсутствующие (нереализованные) фичи.
Квадранты тестирования
Некоторые из этих тестов должны быть автоматизированы, некоторые должны запускаться при помощи разных тулзов, а некоторые должны быть ручными.
Важно поменять у команды мышление и отношение к обеспечению качества. Существует такое понятие, подход как Test-First Thinking. Давайте ответим на простой вопрос. Для чего вообще тестирование? Для того, чтобы получить некую обратную связь по тому что было сделано, реализовано.
В традиционной V-модели, когда вначале описывается фича, потом userstory, потом пишется код. А после этого начинается тестирование кода, тестирование userstory, тестирование фичи.
Традиционная V-модель тестирования. Медленная ОС!
Как видно в такой модели очень медленная обратная связь. А медленная обратная связь тормозит весь процесс создания ценности для клиента. Последствия этого думаю описывать не надо.
C подходом Test-First Thinking и Shift left testing ситуация меняется. Мы получаем очень быструю обратную связь. Как только появляется достаточно реализации, можно запускать тесты для проверки написанного кода, для проверки userstory и фичи. То есть тестирование идёт постоянно! Как результат быстрая обратная связь. Подход Test-First Thinking для кода означает, что ни строчки кода, пока не написан тест и не тестировать код, а кодировать для теста. А для фич и userstory Test-First Thinking реализуется BDD.
Быстрая ОС!
Пирамида тестирования и ее анти-паттерн
Резюмируя скажу, что первый шаг на пути к встраиванию качества в процессы, начинается с работы по смене мышления у команды, и конечно же, аудита тех тестов, которые есть на продукте. Аудит покажет реальную картину с пирамидой тестирования, далее внедрять концепцию Test-First Thinking и Shift left testing.
Эффективное тестирование верстки
Тестировать полезно. Тесты позволяют в автоматическом режиме безопасно рефакторить код и гарантируют его работу. Тесты – это живая документация: если информация в 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 сентября повышение цены. Подписывайтесь на рассылку, в которой присылаем новости, анонсы и промокоды:)