2.3 KiB
Test Intent
Перед нетривиальным тестом сформулируй наблюдаемый результат и риск регрессии в описании задачи/PR, рядом с тестом либо в рабочем отчёте. Отдельный artifact не обязателен. Для trivial low-risk изменения отдельный Test Intent не нужен.
Краткая форма, только применимые пункты:
- Поведение: что увидит пользователь/caller и какую ошибку должен поймать тест.
- Варианты и границы: значимые альтернативы, edge/error states, concurrency.
- Исключено: какие детали реализации не являются контрактом.
- Уровень: самая дешёвая boundary, которая надёжно различает правильный и сломанный исход; критерии — в local testing convention.
Пример: «Два refresh с одним token: один успешный ответ, второй 401; новая session остаётся рабочей. Проверить на реальной изолированной SQLite. Не проверять порядок private calls». Mock race не доказывает DB atomicity.
Для каждого теста ответь: «Какой regression он обнаружит?» Не создавай
Foo.test.tsx из-за появления Foo.tsx. По умолчанию не тестируй obvious JSX,
CSS classes, каждый wrapper/aria attribute, decorators, trivial CRUD wiring,
framework и сторонние библиотеки. Проверяй доступность через пользовательское
действие/смысл, когда это риск; декларативный атрибут сам по себе не test intent.
Bug fix сначала воспроизводит исход на responsible boundary. После подходящих проверок остановись: количество тестов и coverage ради coverage не являются целью. Новые harness/framework/fixtures не нужны, когда существующий setup покрывает риск.