Визуальный гайд для джунов по тестированию фронтенда

«Фронтенд-приложения являются важной частью любой программной системы. Именно здесь пользователи взаимодействуют с системой. Поэтому важно тестировать код фронтенд-приложений до и после развертывания.

Цель этого поста — обзор различных типов фронтенд-тестов:

  • Какие типы существуют
  • Место каждого типа в цикле разработки
  • Область применения каждого типа
  • Используемые технологии и библиотеки

Этот пост написан в контексте ReactJS-приложения, но в целом концепции, изложенные в этом посте, могут быть легко применимы для любого фронтенд-проекта.

Итак, начнем.

Dumb и Smart фронтенд-тесты

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

Прежде чем мы продолжим, давайте напомним о двух типах компонентов, которые мы видим в компонентных фронтенд-проектах (component based).

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

Следующая диаграмма обобщает вышеописанное:

Теперь подробно рассмотрим каждый тип фронтенд-теста.

Юнит-тесты

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

Компоненты, используемые на этом уровне:

Компонентные тесты

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

Технологии на этом уровне:

Снапшот-тесты

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

Технологии:

Тесты доступности на уровне компонентов

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

Технологии:

Контрактное тестирование

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

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

  • Новая версия фронтенд-приложения, которая будет развернута, совместима с уже развернутым сервером API бекенда.
  • Если вы собираетесь развернуть новую версию бекенд-сервера API, мы можем убедиться, что не сломаем текущую версию фронтенд-приложения, которая уже развернута.

Тестирование после развертывания

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

Сквозные тесты

Тесты End-to-End автоматически загружают веб-приложение в браузер и имитируют действия пользователя. Например, тестовый скрипт находит в браузере кнопку, нажимает на нее и ждет, аналогично тому, как это делает реальный пользователь. Затем веб-приложение запускает свою логику, обращается к API-серверу, получает все данные и отображает их соответствующим образом. Затем тестовый скрипт проверяет, что данные отображаются должным образом — так, как они должны быть показаны пользователю.

Обычно эти тестовые скрипты сопоставляются с пользовательскими историями и чаще всего пишутся в формате gherkin.

Применяются технологии:

Тесты доступности

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

Эти тесты охватывают:

  • Проверку структуры страницы, цветового контраста, надписей, форм и мультимедийных функций
  • Валидация чтения с экрана
  • Навигация с помощью клавиатуры

Технологии:

Теория

Тесты производительности

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

Технологии:

Google Lighthouse

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

Источник


Также может быть интересно:

Тестирование фронтенда — большой гайд

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас