Testing Strategy

---
name: testing-strategy
description: Стратегия тестирования — пирамида unit/integration/e2e (что каким уровнем проверять), что мокать а что нет (границы I/O — да, домен — нет), осмысленные пороги покрытия (критичные пути ~100%, UI-обвязка ниже), структура AAA/given-when-then, критерии хорошего теста, причины flaky и их фиксы. Use при проектировании тестов, ревью тестового набора, выборе уровня теста и лечении нестабильных тестов.
version: 1.0.0
---

# Навык: Стратегия тестирования

Ключевой принцип: **зелёный прогон — единственное доказательство**. Тест, который никогда не падал, ничего не проверяет: новый тест сначала покажи красным (прогон без фикса / с намеренно сломанным ожиданием), потом делай зелёным.

## 1. Пирамида: что каким уровнем проверять
| Уровень | Проверяет | Инструменты | Скорость / объём |
|---|---|---|---|
| **Unit** | Чистую логику: функции, ветвления, границы, ошибки | Vitest / Jest / node:test | Миллисекунды, основная масса тестов |
| **Integration** | Связку слоёв: роут → сервис → БД; контракты API | Supertest / `app.inject()`, testcontainers | Секунды, ключевые пути |
| **E2E** | Критический путь пользователя в реальном браузере | Playwright | Десятки секунд, только critical path |

Правило: проверяй на самом **низком** уровне, где ошибка воспроизводима. Ветвления логики — unit, а не e2e; «кнопка реально сохраняет в БД» — integration/e2e, а не 50 unit-моков.

## 2. Раннер проекта — не навязывай свой
Определи по `package.json` (`devDependencies`, `scripts.test`): Vitest / Jest / node:test / Playwright. Пиши в конвенциях проекта (`*.test.ts` рядом с кодом vs `__tests__/`, `describe` vs плоские `test`). Не приноси Vitest в Jest-проект «потому что современнее».

## 3. Что мокать, а что нет
| Мокать | НЕ мокать |
|---|---|
| Границы I/O: сеть (MSW/nock), сторонние API, почта, платежи | Собственную доменную логику |
| Время (`vi.useFakeTimers`), random (фиксированный сид), env | Свою БД в integration-тестах — для этого testcontainers/тест-БД |
| Файловую систему (лучше — tmp-каталог) | Внутренние модули «для скорости» — тест перестаёт проверять связку |

Перемокал — тест проверяет моки, а не код. Недомокал — тест ходит в живые сервисы. Тесты **никогда** не ходят в dev/prod-базу.

## 4. Пороги покрытия — осмысленно
- Деньги, авторизация, безопасность, запись/миграция данных → цель ~100% branch.
- Доменная логика → высоко (80–90% branch).
- UI-обвязка, конфиги, генерируемый код → ниже или исключить из подсчёта.
- Общий «80% везде» — антипаттерн: рождает бессмысленные тесты геттеров и снапшоты всего подряд. **Branch coverage важнее line**: непокрытая ветка — непроверенное решение.

## 5. Структура и нейминг
- **AAA**: Arrange → Act → Assert, блоки визуально разделены пустой строкой.
- Given-when-then в именах: `describe('transfer')` → `it('rejects when balance is insufficient')`.
- Имя читается как спецификация — «что делает при каком условии», не `test1` / `works`.
- Один логический assert на тест (несколько `expect` об одном исходе — нормально).
- Общая подготовка — фабрики/фикстуры, а не copy-paste и не гигантский `beforeEach` со скрытым состоянием.

## 6. Критерии хорошего теста
- Падает по **одной** причине, и сообщение падения сразу говорит, что сломалось.
- Не зависит от порядка запуска и соседей: сам создаёт свои данные, сам убирает (rollback/truncate/afterEach).
- Детерминирован: время, random и сеть под контролем.
- Проверяет **поведение** (наблюдаемый результат), а не реализацию (внутренние вызовы) — иначе ломается при каждом рефакторинге.
- Быстрый настолько, насколько позволяет его уровень пирамиды.

## 7. Причины flaky → фиксы
| Причина | Симптом | Фикс |
|---|---|---|
| sleep/таймауты вместо ожиданий | Падает под нагрузкой / только в CI | Событийное ожидание: `waitFor`, web-first assertions |
| Shared state (общая БД/синглтон/модульная переменная) | Падает при смене порядка тестов | Изоляция данных на тест; rollback/truncate в beforeEach |
| Незамоканное время | Падает в полночь / на границе месяца | Fake timers, инъекция часов |
| Незамоканный random | «Иногда» другой результат | Фиксированный сид |
| Race в async-коде | Редкие падения без изменений кода | Найти race; часто это баг **продакшен**-кода — чини код |
| Утечка ресурсов (порты, коннекты, таймеры) | Падает вторым прогоном подряд | Закрытие в `afterEach`/`finally` |

Flaky-тест — **баг**, а не повод для retry. Доказательство лечения: 10 зелёных прогонов подряд, включая перемешанный порядок (`--sequence.shuffle` в Vitest / `--randomize` в Jest).