План тестов для фичи

Составь план тестов для: {{feature}}.

Шаги

1. Что тестируем — на каждом уровне

2. Декомпозиция по уровням

Unit-тесты (≤ 20 шт):

• Каждая чистая функция
• Граничные значения (0, отрицательные, пустые, очень большие)
• Корректные и некорректные входы
• Не тестируй: getters/setters, тривиальные мапы

Integration-тесты (≤ 10 шт):

• API endpoints: 200, 4xx, 5xx
• БД: транзакции, индексы, миграции
• External services: с моком, с реальным в test-режиме (если SDK позволяет)

E2E (≤ 5 шт):

• Critical path: главный happy flow
• Auth flow
• Платёж / любая транзакционная операция
• Не покрывай мелочи — это дорого

3. Edge cases (важно!)

Спроси: что может пойти не так?

• Пустые / null значения
• Очень большие / очень маленькие числа
• Unicode, emoji, RTL текст
• Concurrent requests
• Прерванная сессия / network failure
• Out of order events
• Idempotency: дубли запросов
• Permissions: пользователь без прав
• Rate limits

4. Что НЕ тестировать

• Реализацию (детали меняются — тест не должен ломаться)
• Внешние библиотеки (тестировано их авторами)
• UI-стили (Visual regression — отдельная категория)
• Тривиальные геттеры

5. Формат плана

## Unit
| # | Что | Файл | Edge cases |

## Integration
...

## E2E
...

## Не тестируем (но осознанно)
- ...

Принципы

• Тест "what" а не "how"
• Один тест — одна assertion (или близко к этому)
• Тест должен падать только когда фича сломана
• Названия тестов — это документация. it("returns 0 when input is empty") > it("works")