- Dumb и Smart тесты
- Юнит-тесты
- Компонентные
- Снапшот-тесты
- Тесты доступности на уровне компонентов
- Контрактное тестирование
- Тестирование после развертывания
- Сквозные тесты
- Тесты доступности
«Фронтенд-приложения являются важной частью любой программной системы. Именно здесь пользователи взаимодействуют с системой. Поэтому важно тестировать код фронтенд-приложений до и после развертывания.
Цель этого поста — обзор различных типов фронтенд-тестов:
- Какие типы существуют
- Место каждого типа в цикле разработки
- Область применения каждого типа
- Используемые технологии и библиотеки
Этот пост написан в контексте ReactJS-приложения, но в целом концепции, изложенные в этом посте, могут быть легко применимы для любого фронтенд-проекта.
Итак, начнем.
Dumb и Smart фронтенд-тесты
Ниже приведена визуализация, показывающая типы фронтенд-тестирования, которые мы будем обсуждать сегодня, и место каждого типа в цикле разработки и развертывания.

Прежде чем мы продолжим, давайте напомним о двух типах компонентов, которые мы видим в компонентных фронтенд-проектах (component based).
- Простые/статические компоненты (Dumb/Static Components) — компоненты, которые используют ТОЛЬКО промежуточные элементы (props) для взаимодействия с внешним миром. Обычно эти компоненты являются «листовыми» (leaf) компонентами в дереве компонентов проекта.
- Умные/контейнерные компоненты (Smart/Container Components) — эти компоненты используют Dumb/Static компоненты для создания более индивидуального пользовательского опыта. Они взаимодействуют с внешним миром различными способами: получение API, изменение глобального состояния приложения и реагирование на изменения глобального состояния. Кастомные хуки (Custom Hooks), которые мы пишем, обычно подпадают в эту категорию.
Следующая диаграмма обобщает вышеописанное:

Теперь подробно рассмотрим каждый тип фронтенд-теста.
Юнит-тесты
Юнит-тесты — самый известный тип тестирования у разработчиков. Они проверяют каждый модуль или компонент фронтенд-приложения по отдельности. Что касается дерева компонентов, то юнит-тесты охватывают простых/статичных компоненты:

Компоненты, используемые на этом уровне:
- Jest — (Фреймворк и раннер тестов на Javascript)
- React Testing Library
Компонентные тесты
Можно определить этот тип как вариант юнит-тестов, специализирующийся на тестировании смарт-компонентов. Поскольку смарт-компоненты взаимодействуют с внешним миром различными способами, важно моделировать эти каналы связи и внешние границы, чтобы мы могли тестировать эти компоненты в изоляции.

Технологии на этом уровне:
- Jest
- React Testing Library
- Mock Service Worker (имитация API-ответов в браузере без создания отдельного мок-сервера)
- Cypress Component Testing
Снапшот-тесты
Компоненты часто меняются. Но разработчики чаще обновляют только логику компонента, не меняя его отображения на странице. Снапшот-тесты позволяют убедиться, что отображение компонента не изменилось.

Технологии:
- Jest /snapshot-testing
- React Testing Library
- Storybook Snapshot Testing
Тесты доступности на уровне компонентов
Тесты доступности нужны чтобы убедиться, что приложение доступно для всех пользователей. Обычно тесты доступности выполняются вручную тестировщиками-экспертами по доступности. Здесь те же библиотеки, и некоторые другие, способные выявлять очевидные проблемы доступности на ранней стадии цикла разработки.

Технологии:
- Jest
- React Testing Library
- Axe Tools — Предоставляет React SDK, который тестирует доступность при рендеринге компонентов
- StoryBook
Контрактное тестирование
Большинству фронтенд-приложений для получения данных требуется сервер API бэкенда. Тестирование контрактов, или контрактное тестирование, помогает убедиться, что API-контракт между фронтенд-приложением и бекендом API-сервера (т.е. API-запросы и ответы) работает и не создаст проблем с совместимостью после деплоя.

Если мы будем следовать принципам контрактного тестирования, ориентированного на потребителя (Consumer Driven Contract Testing) (плейлист на YouTube), мы сможем добиться следующего:
- Новая версия фронтенд-приложения, которая будет развернута, совместима с уже развернутым сервером API бекенда.
- Если вы собираетесь развернуть новую версию бекенд-сервера API, мы можем убедиться, что не сломаем текущую версию фронтенд-приложения, которая уже развернута.

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

Сквозные тесты
Тесты End-to-End автоматически загружают веб-приложение в браузер и имитируют действия пользователя. Например, тестовый скрипт находит в браузере кнопку, нажимает на нее и ждет, аналогично тому, как это делает реальный пользователь. Затем веб-приложение запускает свою логику, обращается к API-серверу, получает все данные и отображает их соответствующим образом. Затем тестовый скрипт проверяет, что данные отображаются должным образом — так, как они должны быть показаны пользователю.
Обычно эти тестовые скрипты сопоставляются с пользовательскими историями и чаще всего пишутся в формате gherkin.
Применяются технологии:
Тесты доступности
Тесты доступности, как и сквозные, также автоматически загружают веб-приложение в инструментированный/симулированный веб-браузер и проверяют визуальный вывод финального рендеринга веб-приложения.
Эти тесты охватывают:
- Проверку структуры страницы, цветового контраста, надписей, форм и мультимедийных функций
- Валидация чтения с экрана
- Навигация с помощью клавиатуры
Технологии:
Тесты производительности
Тесты производительности оценивают скорость веб-приложения и генерируют отчеты/аудиты по производительности, доступности, прогрессивным веб-приложениям, SEO и т. д.

Технологии:
Учитывая особенности конкретного фронтенд-приложения, возможно, нужно будет сосредоточиться на том, чтобы правильно настроить лишь некоторые метрики, а не пытаться настроить все.»
Также может быть интересно: