test-driven-development

name	test-driven-development
description	Use when fixing bugs or writing code in processing/, API/, statistics/, ML-infrastructure — write a failing test before fixing

Test-Driven Development (адаптировано для ML-исследования)

Когда применять

Обязательно (детерминированная логика с контрактом):

• ML-инфраструктура: data_loader, feature builder, metric, benchmark runner, profile validation
• Багфиксы в любом модуле (processing/, API/, statistics/, ML/-инфраструктура)
• Новая детерминированная логика (сортировка, нормализация, экспорт, парсинг)
• Изменение контракта данных (формат CSV, поля фракталов)

Не применять (результат измеряется PF/AUC, не unit-тестом):

• Сам ML-эксперимент: подбор гиперпараметров, перебор архитектур, обучение модели
• Throwaway-прототипы, однократные исследовательские прогоны

RED — тест, воспроизводящий проблему

Для багфикса: тест должен падать на текущем коде, воспроизводя баг. Для новой функции: тест описывает ожидаемое поведение.

pytest tests/test_<module>.py -k "test_<specific_case>" -v

Тест должен упасть ровно по той причине, которую ты фиксишь (не по опечатке, не по импорту).

GREEN — минимальный фикс

Пишешь минимальный код, чтобы тест прошёл. Без рефакторинга «заодно» (правило AGENTS.md: «для bugfix не делать рефакторинг "заодно"»).

pytest tests/test_<module>.py -k "test_<specific_case>" -v  # должен пройти
pytest tests/ -x --tb=short                                  # остальные не сломаны

REFACTOR — только если нужно

После зелёного теста — убрать дублирование, улучшить имена. Без добавления нового поведения.

Отличие от оригинального TDD

Оригинальный скилл требовал: «никакого кода без падающего теста». Это правило не применяется к ML/-экспериментам, где результат измеряется PF на validation/test, а не unit-тестом.

Для processing/API/statistics — дисциплина тестов обязательна как часть контракта docs/methodology/03-feature-contract-leakage.md и общей практики проекта (каталог tests/).

Анти-паттерны тестирования

При написании тестов с моками (особенно для data_loader, валидаторов, benchmark runner) — загружай справочник testing-anti-patterns.md: 5 паттернов с Python-примерами из проектной ML-инфраструктуры.