SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Testing / AGENT SKILL
testing-strategy
0
Стратегия тестирования — пирамида unit/integration/e2e (что каким уровнем проверять), что мокать а что нет (границы I/O — да, домен — нет), осмысленные пороги покрытия (критичные…
Стратегия тестирования — пирамида unit/integration/e2e (что каким уровнем проверять), что мокать а что нет (границы I/O — да, домен — нет), осмысленные пороги покрытия (критичные пути ~100%, UI-обвязка ниже), структура AAA/given-when-then, критерии хорошего теста, причины flaky и их фиксы. Use при проектировании тестов, ревью тестового набора, выборе уровня теста и лечении нестабильных тестов.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# Навык: Стратегия тестирования
Ключевой принцип: **зелёный прогон — единственное доказательство**. Тест, который никогда не падал, ничего не проверяет: новый тест сначала покажи красным (прогон без фикса / с намеренно сломанным ожиданием), потом делай зелёным.
## 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).