Русский | English

Принципы тестирования

Для контрибьюторов и агентов, которые меняют ядро TAUSIK (scripts/, MCP, гейты, хуки). Про поток верификации в CLI см. Глоссарий verify / QG и раздел Verification в CLI.

Когда добавлять или расширять тест

Ситуация	Действие
Изменилось поведение	Добавить или обновить проверки нового наблюдаемого результата (вывод CLI, метод сервиса, строка в БД, решение гейта).
Исправлен баг	Добавить регрессионный тест, который на старом коде падает, а на новом проходит (или явно описать, почему покрытие только интеграционным тестом).
Только рефакторинг	Расширять тесты только там, где иначе падает покрытие критичных путей; не гонять шум ради косметики.

Новый файл или доработка существующего

• Согласованность с basename продакшн-файла. Правки в scripts/foo_bar.py логично класть в tests/test_foo_bar.py — так scoped pytest (маппинг tests/test_<имя>.py по relevant_files при task done / verify) остаётся предсказуемым. Резолвер см. в коде рядом с gate_test_resolver.py и в Архитектуре — Testing.
• Новый модуль tests/test_<область>.py, если появляется новая поверхность или в одном файле смешались несвязанные области (хуже навигация и ревью).
• Дописывать существующий файл, если сценарий того же функционального кластера и размер файла остаётся разумным.

Scoped gates и закрытие задачи

task done / tausik verify --task <slug> используют relevant_files для сопоставления путей с тестами. Пустой список уходит в полный suite (осознанный дефолт). Чувствительные пути не используют reuse verify-cache, но гейты выполняются (Глоссарий verify / QG). Указывайте в relevant_files то, что реально меняли.

Негатив: анти-паттерны

• Копипаста теста без нового поведения. Второй кейс с тем же смыслом и другим именем не повышает надёжность — только шум и время CI. Нужно покрывать новую ветку/инвариант, объединять дубликаты или удалять лишнее.
• «На этот код тесты не пишем» для security-путей. Каталоги вроде scripts/hooks/, auth, billing не освобождаются от проверок — наоборот, там нужна дисциплина и часто усиленное внимание.

См. также

• Архитектура — структура репозитория, гейты, команды тестирования.
• Глоссарий verify / QG — Verify-First, тестовый shim, обход кеша для чувствительных файлов.
• CLI — Верификация — verify, TTL кеша, task done.