Проверяет, что код действительно работает: пишет и запускает тесты, сверяет результат с критерием приёмки из ТЗ, отлаживает по алгоритму «воспроизведи → локализуй → минимизируй → исправь → защити». Применяйте для «проверь / протестируй», «не работает — почини», «покрой тестами», «найди баг», «убедись, что работает». Не подходит для написания основной реализации (dev-build), сбора требований (dev-spec) или ведения проекта (dev-project).

Тестирование и отладка

Доказать, что код работает — не «кажется working», а проверяемое свидетельство. Две задачи навыка: проверить (тесты + сверка с ТЗ) и починить (отладка).

Когда активирован

• «Проверь / протестируй / убедись, что работает».
• «Не работает / падает / выдаёт не то — почини».
• «Покрой тестами», «напиши тесты», «найди баг».
• После реализации среза (dev-build) — как выходной контроль.

Не активируй для написания основной реализации (dev-build) или сбора требований (dev-spec).

Главный принцип: свидетельство, а не мнение

«Я запустил — работает» ≫ «должно работать». Тест или ручной прогон с реальным вводом — это свидетельство. Любое утверждение «работает» должно опираться на: тест зелёный, команда выполнена с таким-то выводом, ввод X дал вывод Y. Без этого — это догадка.

Критерий приёмки из SPEC.md — это спецификация проверки. Если в SPEC.md написано «пользователь вставляет ссылку → получает график за 30 дней», то тест именно это и прогоняет: реальная ссылка → есть график → 30 точек.

Часть 1. Проверка

Пирамида тестов (не перегружай)

Для MVP достаточно одного-двух слоёв — не строй корпоративную пирамиду:

1. Юнит-тесты на ключевую логику (вычисления, парсинг, валидация) — обязательно.
2. Один сквозной тест на核心ный путь пользователя (критерий приёмки) — желательно.
3. E2E/UI-автоматизация — отложить, для MVP обычно избыточна; ручной прогон дешевле.

Лёгкий red-green

• Сначала тест падает (red) на нужном поведении, потом код делает его зелёным.
• Это защищает от теста, который ничего не проверяет.
• Для бага: сначала тест, воспроизводящий баг (red) → фикс → тест зелёный. Так баг закрыт доказуемо и не вернётся.

Сверка с критерием приёмки

Пройдись по SPEC.md и для каждого пункта приёмки ответь: «каким тестом/прогоном это доказано?». Если пункт не покрыт — это либо дыра, либо его не нужно было в MVP (тогда убрать из SPEC). Не оставляй непроверенные требования.

Как запускать (кросс-платформа)

• Python: pytest -q (есть pytest) или простой python -m unittest.
• Node: node --test (встроено, без зависимостей) или npm test.
• Без фреймворка: минимальный скрипт test.js/test.py, который печатает OK/FAIL и выходит с кодом 0/1. Этого достаточно для MVP.
• Не предполагай bash — команды запуска давай на языке проекта (см. dev-build §кросс-платформа).

Часть 2. Отладка (когда не работает)

Алгоритм из пяти шагов — не перепрыгивай:

1. Воспроизведи надёжно. Нельзя починить то, что не воспроизводишь. Зафиксируй точные шаги, ввод, окружение. Если плавающий баг — найди условия, при которых он повторяется стабильно.
2. Локализуй. Сузь область: убери всё лишнее, оставь минимальный ввод, на котором баг есть. Бинарный поиск по коду/коммитам (отключай половину — баг остался?).
3. Минимизируй тест-кейс до самого короткого, на котором баг воспроизводится. Короткий кейс = быстрая проверка фикса.
4. Исправь корень, а не симптом. Понимай почему баг возник, не лепи заплатку, гасящую проявление. Заплатка порождает следующий баг рядом.
5. Защити: добавь тест на этот кейс (чтобы не вернулся) и проверь, не сломал ли фикс что-то ещё (регрессия — прогони остальные тесты).

Анти-паттерны отладки

• «Поменяю наугад, вдруг пройдёт» — это не отладка, это лотерея. Сначала локализуй.
• «Заккомментирую падающий кусок» — симптом, а не корень. Тест потом всё равно упадёт.
• «У меня работает» — а у пользователя нет. Проверяй в условиях пользователя (ОС, данные).

Границы (✅ / ⚠️ / 🚫)

• ✅ Всегда: тест на核心ную логику; тест-кейс для каждого бага; прогонять после фикса всю смежную область.
• ⚠️ Спросить: внедрять тяжёлый тест-фреймворк/E2E-инфраструктуру в MVP; менять схему ради тестируемости.
• 🚫 Никогда: не удалять падающий тест; не помечать баг «починил» без зелёного теста на кейс; не глушить вывод ошибок, чтобы «выглядело чисто».

Отговорки и почему они не работают

Выходные критерии

• Критерий приёмки из SPEC.md покрыт тестом или воспроизводимым прогоном.
• Каждый найденный баг закрыт тестом-кейсом (зелёным после фикса).
• Регрессия проверена — смежные тесты зелёные.
• Если что-то не покрыто или не чинится — честно сказано пользователю, что осталось и какой риск (без «вроде готово»).