Как тестируют фронтенд

Когда вы открываете сайт, кликаете по кнопке «Купить», выбираете товар или просто листаете новостную ленту — всё, что вы видите и с чем взаимодействуете, это фронтенд. Он рисует интерфейс, показывает данные и реагирует на действия пользователя. А вот чтобы эта кнопка действительно что-то делала, новости подгружались, а товары в корзине считались — тут уже подключается бэкенд. Но если фронтенд сломается, пользователь даже не дойдёт до всех этих процессов. Поэтому фронтенд, как и любую часть приложения, важно как следует тестировать.

В этой статье разберемся, зачем тестировать фронтенд, как это делать и какими инструментами.

Что такое фронтенд

Фронтенд — это всё, что видит и трогает пользователь в браузере: интерфейсы, кнопки, меню, анимации, формы, изображения и тексты. Это внешняя часть сайта или веб-приложения, с которой вы взаимодействуете.

Фронтенд собирается из HTML (структура), CSS (оформление) и JavaScript или TypeScript (логика и интерактив). На этом строится всё, от простых лендингов до сложных интерфейсов интернет-банков.

Хороший фронтенд — это не просто «чтобы красиво». Он должен быть быстрым, удобным, адаптивным, доступным и работать без сбоев.

Зачем тестировать фронтенд

В реальности фронтенд — штука хрупкая. Обновил зависимость? Сломалась форма. Добавил новый блок? Поехала вёрстка на iPhone. Поменял кнопку? Она больше не нажимается. А если проект растёт, разработчиков становится больше, то без тестов каждый коммит — это потенциальный взрыв где-то в интерфейсе.

Тесты нужны, чтобы:

Бизнесу это тоже выгодно: меньше инцидентов = меньше потерь. Даже пара хорошо написанных тестов может сэкономить сотни часов и много денег компании. Так что тесты — это страховка.

А если не тестировать будет боль. Постоянные баги, катастрофы в Safari, верстка, которая едет на глазах, и пользователи, которые закрывают сайт и больше не возвращаются.

Направления тестирования

Фронтенд можно (и нужно) тестировать с разных сторон. Все тесты можно условно разбить на несколько направлений в зависимости от того, что именно мы проверяем и на каком уровне. Это хорошо иллюстрирует пирамида тестирования: внизу — быстрые и простые юнит-тесты, выше — интеграционные, а на вершине — медленные, но самые приближённые к реальности E2E. Чем выше — тем дороже и сложнее.

Разберем каждый вид более подробно.

Юнит-тесты (unit tests)

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

Например:

Сам по себе юнит-тест — это функция, в которой мы закладываем ожидаемое поведение кода: подаём входные данные и проверяем, что результат такой, как надо. Обычно используется структура Arrange → Act → Assert: сначала настраиваем окружение и входные данные, потом вызываем нужную функцию или компонент, а в конце проверяем, что всё сработало правильно. Эти тесты супербыстрые и помогают ловить ошибки до того, как запустится сборка проекта. 

Интеграционные тесты (integration tests)

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

В каждом из этих кейсов важно, чтобы вся цепочка действий работала без сбоев. Юнит-тесты могли бы по отдельности сказать, что всё норм, но если компоненты плохо взаимодействуют между собой — всё сломается.

Интеграционные тесты как раз помогают найти такие баги: проверяют, что кнопка реально запускает нужную логику, что состояние передаётся правильно, что компонент отрисовался в ответ на действие.

E2E-тесты (end-to-end)

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

Например, если тестируем сайт, где можно записаться к врачу,  это может выглядеть так:

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

Визуальное тестирование

Иногда баг не в логике, а в том, как компонент выглядит. Отступ пропал, кнопка стала меньше, шрифт сменился, текст вылез за рамки или всё просто поехало в Safari — и никто не заметил. В юнитах и E2E-тестах такие штуки почти не ловятся, но визуальные тесты их отслеживают. Суть в том, что инструменты делают виртуальный скриншот компонента и сравнивают его с эталоном. Если что-то изменилось — тест падает, вы это видите и решаете: баг это или так действительно нарисовали великие дизайнеры.

Это особенно важно, если:

Также сюда относится тестирование доступности (accessibility, или a11y). Даже если всё выглядит красиво, сайт может быть неудобен для людей с нарушениями зрения или моторики. Автоматические a11y-тесты помогают найти такие проблемы: отсутствие alt у изображений, неправильная структура заголовков, недоступные элементы управления и прочее.

Тестирование структуры компонентов (для React)

Ещё есть снапшот-тестирование — это когда мы отслеживаем неожиданные изменения в структуре компонентов. Оно не проверяет внешний вид или поведение, а просто фиксирует, как структурно выглядел JSX-компонент на момент написания теста.

Допустим, отрендерился компонент UserCard с пропсами, и Jest делает «фото» его виртуального DOM в виде текстового файла. В следующий раз, когда мы запускаем тесты, Jest сравнивает текущее «фото» с сохранённым. Если отличается — тест падает.

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

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

Инструменты для тестирования

Когда уже понятно, что тестировать, нужно выбрать, чем. Посмотрим на самые популярные инструменты: от юнитов до E2E.

Jest

Jest — это JS-фреймворк для юнит- и интеграционных тестов. Основа почти для всего. Подходит для тестирования функций, компонентов, хуков — особенно в React-проектах.

Пример простого юнит-теста с использованием Jest: здесь мы проверяем, что функция uppercase корректно обрабатывает пустую строку и выбрасывает ожидаемую ошибку:

Testing Library

Testing Library — это целая экосистема инструментов для тестирования пользовательского интерфейса глазами пользователя, а не изнутри кода.

Чтобы не искать кнопки по className или проверять, вызывался ли какой-нибудь onClick, здесь мы работаем с позиции пользователя: видим текст — кликаем, вводим, смотрим, что появилось на экране. Сначала рендерим компонент в виртуальном DOM (jsdom), а затем работаем с ним, как реальный пользователь.

Библиотека поддерживает разные фреймворки — React, Vue, Angular. Идеально сочетается с Jest — вместе они дают быстрые и понятные тесты, которые легко читать. Такой подход позволяет не привязываться к реализации компонентов и писать долгоживущие, устойчивые тесты, которые не разваливаются при каждом рефакторинге.

Пример теста с использованием Testing Library и Jest: компонент App рендерится, и проверяется наличие текста learn react в DOM:

Cypress

Cypress — это мощный инструмент для E2E‑тестирования, который позволяет тестировать веб-приложения так, будто реальный пользователь кликает кнопки, вводит данные и взаимодействует с сайтом в браузере.

Допустим, вот так может выглядеть полноценный E2E-тест для фронтенда:

describe('Проверка формы логина', () => {
  it('Успешный вход', () => {
    cy.visit('/login')
    cy.get('input[name="email"]').type('test@example.com')
    cy.get('input[name="password"]').type('123456')
    cy.get('button[type="submit"]').click()
    cy.contains('Добро пожаловать')
  })
})

Cypress открывает страницу, вводит данные, жмёт на кнопку и проверяет, что появился нужный текст. Справа мы видим, как тест запускается в браузере и пошагово проверяет работу React-приложения Todo List. Слева — код самого компонента на React, который управляет списком задач.

Playwright

Playwright — это альтернатива Cypress, мощный инструмент от Microsoft. Быстрый, параллельный, поддерживает Chromium, Firefox, WebKit. Можно писать тесты и запускать их в headless-режиме. Особенно хорош для CI/CD и продвинутых сценариев.

Вот как выглядит автоматическая запись E2E-теста в Playwright прямо в VS Code (смотрим в левый нижний угол): действия пользователя превращаются в код — удобно для быстрого создания тестов без ручного написания.

Storybook + Chromatic

Используют для визуального тестирования компонентов. Storybook — это по сути интерактивная витрина ваших UI-компонентов. Chromatic подключается к ней и делает снапшоты внешнего вида. Любое изменение — и сразу видно, что поехало по вёрстке.

Вот как Storybook показывает все состояния компонента Button в изоляции — удобно для визуального тестирования и документации UI:

Percy / Applitools

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

Работает это так: вы запускаете тесты (например, при пуше в GitHub), затем Percy или Applitools делают скриншоты ключевых экранов или компонентов. Сравнивают их с предыдущими эталонными версиями, и если появился новый отступ, кнопка сдвинулась или цвет изменился — то тест падает и вы получаете наглядный отчёт с подсвеченными отличиями.

Пример визуального теста в Applitools: инструмент сравнивает текущую верстку со «снимком» из прошлого запуска и находит отличия — например, увеличенный логотип или смещение элементов:

Где научиться 

У Яндекс Практикума есть курсы, которые подходят и новичкам, и тем, кто хочет перейти из ручного тестирования в автоматизацию:

Во всех курсах есть бесплатная часть: можно попробовать и посмотреть, как идёт. И самое важное — вы работаете с ментором, у вас есть код-ревью и настоящие проекты.

Вам слово

Приходите к нам в соцсети поделиться своим мнением о статье и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!