Test & Debug
@dev-test
Verifies the code actually works: writes and runs tests, checks the result against the spec's acceptance criteria, runs lint and typecheck, debugs with the reproduce → localize → minimize → fix → guard loop. Use when the user says «проверь / протестируй», «не работает — почини», «покрой тестами», «найди баг», «убедись, что работает». Do NOT use for writing the main implementation (dev-build), requirements (dev-spec), deployment (dev-deploy), or project tracking (dev-project).
Who the Test & Debug skill is for
- Developers and freelancers — prove the code works, not «seems to work».
- MVP teams — cover the core logic with tests without overloading on a corporate pyramid.
- Anyone fixing bugs — debug by an algorithm, not by guessing.
- Clients and product managers — check the result against the spec's acceptance criterion.
What you can do
- Verify the code works — a test or a manual run with real input as evidence.
- Cover the core logic with tests — unit tests on calculations, parsing, validation plus one end-to-end test on the main path.
- Find and fix a bug — with the «reproduce → localize → minimize → fix the root → guard» algorithm.
- Check against the acceptance criterion — for each item in SPEC.md, answer which test proves it.
Related skills: Build, Spec & Architecture, Project Tracking.
How it works: evidence, not opinion
Any claim that it «works» rests on a fact: a green test, a command that exited with this output, input X produced output Y. For a bug, light red-green is used — first a test that reproduces it (red), then a fix that turns it green. That way the bug is provably closed and won't come back. The acceptance criterion from SPEC.md is the test specification: if it says «paste a link → get a 30-day chart», the test runs exactly that.
Useful details
- The five-step debug algorithm can't be skipped: reproduce reliably first, then localize.
- The root, not the symptom: a patch breeds the next bug nearby.
- Cross-platform runs: Python —
pytest -q, Node —node --test(built in, no dependencies). - Regression: after a fix, all neighbouring tests are run.
Ready to prove it works? Launch the Test & Debug skill or start with the AI Developer.
What counts as proof that the code works?
A green test or a manual run with real input. «I ran it — it works» beats «it should work»: a green test, a command that exited with this output, input X produced output Y. Without verifiable evidence it's a guess.
How many tests does an MVP need?
One or two layers, no corporate pyramid: unit tests on the core logic (calculations, parsing, validation) — mandatory, and one end-to-end test on the main user path — desirable. E2E/UI automation is usually overkill for an MVP.
How are bugs fixed?
With a five-step algorithm you can't skip: reproduce reliably → localize (narrow the scope) → minimize the test case → fix the root, not the symptom → guard with a test so the bug doesn't return.
Can I comment out a failing test?
No. That fights the symptom, not the cause — the bug comes back elsewhere. A failing test must not be deleted; first reproduce and localize, then fix the root.
How do I run tests cross-platform?
Python — pytest -q or python -m unittest; Node — node --test (built in, no dependencies) or npm test. Commands come in the project's language, with no assumption of bash.
Is it paid?
You can use the skill within your AgentHere plan — you pay tokens as the model runs. See the pricing page for exact limits.
Тестирование и отладка
Доказать, что код работает — не «кажется, работает», а проверяемое свидетельство. Две задачи навыка: проверить (тесты + сверка с ТЗ) и починить (отладка).
Когда активирован
- «Проверь / протестируй / убедись, что работает».
- «Не работает / падает / выдаёт не то — почини».
- «Покрой тестами», «напиши тесты», «найди баг».
- После реализации среза (dev-build) — как выходной контроль.
Не активируй для написания основной реализации (dev-build) или сбора требований (dev-spec).
Главный принцип: свидетельство, а не мнение
«Я запустил — работает» ≫ «должно работать». Тест или ручной прогон с реальным вводом — это свидетельство. Любое утверждение «работает» должно опираться на: тест зелёный, команда выполнена с таким-то выводом, ввод X дал вывод Y. Без этого — это догадка.
Критерий приёмки из SPEC.md — это спецификация проверки. Если в SPEC.md написано
«пользователь вставляет ссылку → получает график за 30 дней», то тест именно это и
прогоняет: реальная ссылка → есть график → 30 точек.
Часть 1. Проверка
Пирамида тестов (не перегружай)
Для MVP достаточно одного-двух слоёв — не строй корпоративную пирамиду:
- Юнит-тесты на ключевую логику (вычисления, парсинг, валидация) — обязательно.
- Один сквозной тест на ключевой путь пользователя (критерий приёмки) — желательно.
- E2E/UI-автоматизация — отложить, для MVP обычно избыточна; ручной прогон дешевле.
Лёгкий red-green
- Сначала тест падает (red) на нужном поведении, потом код делает его зелёным.
- Это защищает от теста, который ничего не проверяет.
- Для бага: сначала тест, воспроизводящий баг (red) → фикс → тест зелёный. Так баг закрыт доказуемо и не вернётся.
Сверка с критерием приёмки
Пройдись по SPEC.md и для каждого пункта приёмки ответь: «каким тестом/прогоном это доказано?». Если пункт не покрыт — это либо дыра, либо его не нужно было в MVP (тогда убрать из SPEC). Не оставляй непроверенные требования.
Как запускать (кросс-платформа)
Сначала посмотри, как тестируется проект, — не предполагай фреймворк. Загляни в
README.md и package.json/pyproject.toml (поле scripts.test / [tool.pytest]):
там настоящая команда. Типичные варианты:
- Python:
pytest -q(если pytest в зависимостях) илиpython -m unittest. - Node:
npm test(если определён) илиnode --test(встроено, без зависимостей). - Без фреймворка: минимальный скрипт
test.js/test.py, который печатает OK/FAIL и выходит с кодом 0/1. Этого достаточно для MVP. - Не предполагай bash — команды запуска давай на языке проекта (см. dev-build §кросс-платформа).
Линт и тайпчек — тоже проверка
После реализации (и перед «готово») прогони линт и тайпчек, если они есть в
проекте: ruff check / flake8 (Python), npm run lint / tsc --noEmit (Node/TS),
cargo clippy (Rust). Найденные предупреждения — или исправь, или честно скажи,
что осталось. Зелёные тесты при красном линте — не «готово».
Часть 2. Отладка (когда не работает)
Алгоритм из пяти шагов — не перепрыгивай:
- Воспроизведи надёжно. Нельзя починить то, что не воспроизводишь. Зафиксируй точные шаги, ввод, окружение. Если плавающий баг — найди условия, при которых он повторяется стабильно.
- Локализуй. Сузь область: убери всё лишнее, оставь минимальный ввод, на котором баг есть. Бинарный поиск по коду/коммитам (отключай половину — баг остался?).
- Минимизируй тест-кейс до самого короткого, на котором баг воспроизводится. Короткий кейс = быстрая проверка фикса.
- Исправь корень, а не симптом. Понимай почему баг возник, не лепи заплатку, гасящую проявление. Заплатка порождает следующий баг рядом.
- Защити: добавь тест на этот кейс (чтобы не вернулся) и проверь, не сломал ли фикс что-то ещё (регрессия — прогони остальные тесты).
Анти-паттерны отладки
- «Поменяю наугад, вдруг пройдёт» — это не отладка, это лотерея. Сначала локализуй.
- «Заккомментирую падающий кусок» — симптом, а не корень. Тест потом всё равно упадёт.
- «У меня работает» — а у пользователя нет. Проверяй в условиях пользователя (ОС, данные).
Границы (✅ / ⚠️ / 🚫)
- ✅ Всегда: тест на ключевую логику; тест-кейс для каждого бага; прогонять после фикса всю смежную область.
- ⚠️ Спросить: внедрять тяжёлый тест-фреймворк/E2E-инфраструктуру в MVP; менять схему ради тестируемости.
- 🚫 Никогда: не удалять падающий тест; не помечать баг «починил» без зелёного теста на кейс; не глушить вывод ошибок, чтобы «выглядело чисто».
Отговорки и почему они не работают
| Отговорка | Почему мимо |
|---|---|
| «Это и так очевидно работает» | Очевидно ≠ доказано. Один прогон с реальным вводом — и готово. |
| «Тесты замедлят MVP» | Один баг в проде стоит дороже десяти тестов. Минимум — на ключевую логику. |
| «Поменяю, потом проверю» | Сначала воспроизведение и локализация. Иначе чинишь не то. |
| «Заккомментирую, чтобы зелено» | Симптом. Баг вернётся в другом месте. |
Выходные критерии
- Критерий приёмки из SPEC.md покрыт тестом или воспроизводимым прогоном.
- Каждый найденный баг закрыт тестом-кейсом (зелёным после фикса).
- Регрессия проверена — смежные тесты зелёные.
- Линт/тайпчек (если есть в проекте) зелёные или честно перечислены остатки.
- Если что-то не покрыто или не чинится — честно сказано пользователю, что осталось и какой риск (без «вроде готово»).