Тестирование 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. Risk map и test strategy

Сделайте risk-based test plan для login form, checkout step, search results или settings form.

Ответьте:

1. Senior q-17: как выстраивать тестовую стратегию фронтенда.
2. Senior q-16: какие quality gates должны быть в CI.
3. Playbook q-7: как добавить risk management, rollout и rollback в ответ.

Артефакт: таблица risk, user impact, unit, integration, e2e, manual/monitoring, owner, assertion.

Готово, если каждый тест связан с конкретным риском, а для дорогого e2e есть причина, почему unit/integration не хватает.

2. Переписывание brittle tests

Возьмите 3 нестабильных или хрупких теста и перепишите их как проверки пользовательского поведения.

Используйте:

1. Testing strategy pack: negative path, boundary case, accessibility assertion и flaky-test hypothesis.
2. Interview pattern taxonomy: quality-gate.
3. Senior q-16: flaky policy и разделение PR/nightly/release gates.

Артефакт: brittle-test rewrite note для каждого теста: что делало тест хрупким, какой user signal теперь проверяется, какие данные стабилизированы, какой failure action в CI.

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

3. E2E smoke pack для релиза

Соберите 5 smoke-сценариев для release candidate и разделите их на PR, nightly, release и manual fallback.

Ответьте:

1. Senior q-16: CI gate matrix.
2. Senior q-17: минимально достаточные unit/integration/e2e.
3. Playbook q-7: условия остановки релиза.

Артефакт: smoke pack table flow, risk, test layer, trigger, assertion, data setup, rollback/stop signal, owner.

Готово, если smoke pack проверяет не "страница открылась", а критичный пользовательский результат и понятный stop signal.

4. Test governance

Опишите, как команда управляет качеством тестов после внедрения.

Соберите:

1. flaky register с test, symptom, suspected cause, owner, deadline, temporary signal;
2. quality gate policy для PR, nightly, release;
3. метрики flaky rate, defect escape rate, test duration, CI lead time.

Артефакт: test governance memo на 1 страницу.

Готово, если по каждому падению CI понятно: блокируем релиз, отправляем в quarantine, заводим исправление или принимаем осознанный риск.

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

1. Основной мост: Testing strategy pack.
2. Вопросы для интервью: Senior q-16, Senior q-17, Playbook q-7.
3. Паттерн ответа: Interview pattern taxonomy -> quality-gate.
4. Повтор через 24 часа: без подсказок объясните один risk -> test layer -> assertion -> gate -> rollback/stop signal.

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

Ready: вы за 60 секунд объясняете тестовую систему через risk map, показываете smoke pack, называете flaky policy и защищаете, почему выбранный набор тестов экономически оправдан.

Partial: вы знаете unit/integration/e2e, но не можете связать каждый тест с риском, owner, assertion или gate.

Not ready: вы предлагаете "добавить больше тестов", не различаете PR/nightly/release checks и не можете сказать, что делать с flaky e2e.

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

1. Risk-based test plan.
2. Brittle-test rewrite notes для 3 тестов.
3. E2E smoke pack с PR/nightly/release split.
4. Flaky register и quality gate policy.
5. 3 сильных interview-ответа: test strategy, CI gates, risk management.

Куда дальше

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