Перейти к основному содержимому

Тестирование frontend

Для чего модуль​

Построить тестовую систему, которая уменьшает дефекты в релизе и при этом не парализует скорость разработки.

Результат после прохождения​

  1. Вы выбираете тип теста под риск и цель, а не «по привычке».
  2. Вы строите сбалансированную test strategy (unit/integration/e2e).
  3. Вы снижаете flaky rate и повышаете доверие к CI.
  4. Вы связываете тесты с quality gates и релизным процессом.

Термины и аббревиатуры​

ТерминКоротко
UnitПроверка отдельной единицы
IntegrationПроверка взаимодействия
E2EПроверка пользовательского пути
FlakyНестабильный тест
RegressionПоломка ранее рабочего поведения

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Возьмите один критичный пользовательский сценарий и покройте его на разных уровнях.
  2. Для каждого теста фиксируйте, какой риск он покрывает.
  3. Ведите журнал flaky-тестов и причин нестабильности.

Программа модуля​

Урок 1. Тестовая стратегия​

Цель: выстроить систему тестов по рискам продукта.

Risk-based подход​

  1. Критичные user flows тестируются глубже.
  2. Низкорисковые зоны не переинвестируются в дорогие e2e.
  3. Покрытие — не цель само по себе, а индикатор пробелов.

Test pyramid / test trophy​

  1. Unit — быстро и дешево, но ограниченный контекст.
  2. Integration — проверка взаимодействий и контрактов.
  3. E2E — высокая уверенность, высокая стоимость поддержки.

Где ломается в проде​

  1. Слишком много e2e и почти нет unit/integration.
  2. Тестируют implementation details, а не поведение.
  3. Нет карты рисков, поэтому тесты покрывают «не то».

Мини-задача (обязательная)​

Сделайте risk map для одного продукта и распределите тесты по уровням с объяснением, почему именно так.

Что спросит интервьюер: почему ваша тестовая стратегия именно такая и как она связана с рисками продукта.

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

Урок 2. Unit и integration на frontend​

Цель: писать тесты, которые улавливают реальные регрессии и остаются поддерживаемыми.

Unit тесты​

  1. Тестируйте детерминированную бизнес-логику и утилиты.
  2. Избегайте привязки к внутренней реализации компонента.
  3. Минимизируйте ложноположительные проверки.

Integration тесты​

  1. Проверяйте связки «компонент + state + API layer (mocked boundary)».
  2. Тестируйте пользовательское поведение, а не внутренние вызовы.
  3. Учитывайте loading/error/empty states.

Где ломается в проде​

  1. Моки не соответствуют реальным контрактам API.
  2. Тесты проходят локально, но нестабильны в CI.
  3. Большой объем snapshot-тестов без ценности.

Мини-задача (обязательная)​

Покройте один flow тремя тестами: unit для логики, integration для UI-поведения, негативный сценарий ошибки.

Что спросит интервьюер: что именно должны тестировать integration-тесты и чем они отличаются от unit.

Критерий готовности по уроку: ваши unit/integration тесты ловят реальные регрессии и не ломаются от косметических правок.

Урок 3. E2E и качество релиза​

Цель: использовать e2e как контроль критичных сценариев, а не как замену всей тестовой пирамиды.

Где e2e дает максимальную ценность​

  1. Сквозные user journeys (auth, checkout, payment, submission).
  2. Регрессии интеграции между подсистемами.
  3. Smoke-проверки на release candidate.

Стабильность e2e​

  1. Детеминированные тестовые данные.
  2. Явные ожидания готовности, без «магических sleep».
  3. Изоляция окружения и минимизация внешней нестабильности.

Где ломается в проде​

  1. Один большой e2e-suite блокирует delivery.
  2. Флейки игнорируются, доверие к тестам падает.
  3. Нет разделения smoke/regression/nightly.

Мини-задача (обязательная)​

Соберите e2e smoke pack из 5 критичных сценариев и определите, что запускается на каждый PR, а что nightly.

Что спросит интервьюер: как вы боретесь с flaky e2e и не убиваете скорость команды.

Критерий готовности по уроку: вы можете поддерживать e2e-набор как надежный релизный сигнал.

Урок 4. Метрики и операционка тестирования​

Цель: управлять качеством тестирования как процессом команды.

Полезные метрики​

  1. Flaky rate.
  2. Defect escape rate.
  3. Test duration и CI lead time.
  4. Change failure rate после релизов.

Quality gates​

  1. Блокирующие и неблокирующие проверки.
  2. Политика quarantine для flaky тестов.
  3. Правила, когда тестовый долг становится релизным риском.

Где ломается в проде​

  1. Метрики есть, но решений по ним не принимают.
  2. CI сигнал шумный, команда начинает его игнорировать.
  3. Нет владельца за тестовую платформу.

Мини-задача (обязательная)​

Опишите test governance: метрики, пороги, ownership, действия при деградации.

Что спросит интервьюер: какие метрики тестирования вы считаете реально полезными и почему.

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

Практика​

  1. Составьте test strategy для одного продукта по risk map.
  2. Перепишите 3 brittle теста в устойчивый формат.
  3. Подготовьте smoke checklist на релиз.
  4. Закрепите в Middle JavaScript и React и Senior Frontend.
  5. Отработайте один сценарий в Песочнице.

Связь с треками и вопросами​

  1. Треки: Junior трек, Middle трек, Senior трек.
  2. Вопросы: Middle JavaScript и React, Senior Frontend.
  3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности​

Вы можете объяснить тестовую систему проекта через риски, стоимость и реальное влияние на релизное качество.

Артефакты после модуля​

  1. Документ test strategy.
  2. Flaky register и remediation plan.
  3. Smoke pack и quality gate правила.
  4. Набор из 5 сильных interview-ответов по тестированию.

Куда дальше​

  1. Tooling и Delivery
  2. Git для командной разработки
  3. Тестирование frontend