Самый надёжный способ заставить агента писать рабочий код — сначала тест, потом реализация. Разберём цикл red-green-refactor, как ставить задачу и как сделать так, чтобы Claude сам гонял тесты, а не доверял себе на слово.
Главная боль работы с агентом — он уверенно говорит «готово, работает», а на деле код падает на первом же запуске. TDD (Test-Driven Development, разработка через тесты) лечит ровно это: ты заставляешь агента сначала описать ожидаемое поведение тестом, а потом писать код, пока тест не станет зелёным. Доверие на слово заменяется на зелёную галочку — объективный сигнал, что поведение действительно есть.
Что узнаешь из гайда
Часть 1 · Понятие
Главное
TDD — это писать тест до кода. Тест описывает, что функция должна делать. Агент пишет реализацию, пока тест не станет зелёным. Тест — это контракт, а не догадка.
Расшифруем по словам. Тест — это маленькая программа, которая запускает твой код и проверяет: «при входе X результат должен быть Y». Если результат совпал — тест зелёный, прошёл. Если нет — красный, упал. TDD переворачивает привычный порядок: сначала пишется тест на поведение, которого ещё нет, и он закономерно падает; потом пишется код, чтобы тест прошёл.
С обычным человеком это вопрос дисциплины. С агентом — это инструмент контроля. Claude Code умеет писать уверенный код, который выглядит правильным, но содержит тихие ошибки. Тест, написанный заранее, не даёт агенту обмануть ни тебя, ни себя: пока тест красный — работа не сделана, и это видно объективно, а не «на глаз».
Зелёный тест — это доказательство, а «готово, работает» — это обещание.
Часть 2 · Цикл
Главное
Три шага по кругу: red (написали падающий тест), green (написали минимальный код, тест прошёл), refactor (почистили код, тесты остались зелёными).
Это сердце TDD. Каждая новая возможность проходит три фазы, и порядок важен. Разберём по шагам:
| Фаза | Что делает агент | Сигнал |
|---|---|---|
| Red | Пишет тест на новое поведение | Тест падает (его ещё нечем пройти) |
| Green | Пишет минимальный код под тест | Тест проходит, зелёный |
| Refactor | Чистит код, не меняя поведение | Тесты остаются зелёными |
Фаза «red» неочевидна для новичка: зачем специально писать падающий тест? Затем, что падение доказывает — тест вообще проверяет то, что надо. Тест, который зелёный с самого начала (ещё до кода), бесполезен: он ничего не проверяет. Сначала убеждаемся, что тест умеет падать, потом делаем его зелёным кодом.
Важно
«Минимальный код» на фазе green — это буквально самое простое, что проходит тест. Не давай агенту писать сразу красивую универсальную реализацию: добавляй поведение по одному тесту. Так каждый кусок кода рождается под конкретную проверку, а не «на всякий случай». Лишний код без теста — это будущий баг.
Часть 3 · Промт
Главное
В промте явно скажи: сначала тест, дай ему упасть, потом код. Без этой фразы агент по привычке напишет код, а тесты подгонит под него — это уже не TDD.
Агент делает то, что попросили. Если просто сказать «сделай функцию и напиши тесты» — он напишет реализацию, а потом тесты, которые повторяют её поведение (включая ошибки). Чтобы получить настоящий TDD, задай порядок явно:
# Явно задаём порядок: тест первым, падение, потом код
Реализуем функцию parsePrice(str): из строки "1 290 ₽" вернуть число 1290.
Работай по TDD:
1. Сначала напиши тест на ожидаемое поведение (вход → результат)
2. Запусти тест, покажи что он падает (поведения ещё нет)
3. Напиши минимальный код, чтобы тест прошёл
4. Запусти снова, покажи что зелёный
Команда тестов: npm testОбрати внимание на две детали. Первая — дан пример вход → результат прямо в задаче: агенту не нужно угадывать, что считать правильным. Вторая — указана команда запуска тестов (npm test): без неё агент не знает, чем гонять, и может просто описать тест словами вместо реального прогона.
Хорошая постановка задачи — половина результата. Если промты пока даются тяжело, разбор формата задач для агента есть в гайде про промтинг для Claude Code: контекст, конкретика, пример ожидаемого результата.
Часть 4 · Запуск
Главное
Claude Code запускает тесты сам через терминал: видит падение, читает ошибку, правит код, запускает снова — пока не станет зелёным. Тебе остаётся проверить итог.
Сила TDD с агентом в том, что цикл закрывается без тебя. Claude вызывает тест-раннер сам, читает вывод, видит на какой строке упало, и чинит код по реальной ошибке, а не по догадке. Это та же логика, что в отладке: сначала факт (текст ошибки), потом фикс. Подробнее этот подход разобран в гайде про отладку с Claude Code.
В обычном интерактивном режиме агент будет спрашивать разрешение перед запуском команды. Если ты гоняешь TDD-цикл часто или в фоновом (headless) режиме, разрешения на нужные инструменты выдаются заранее одним флагом:
# --allowedTools заранее разрешает агенту терминал, чтение и правки.
# Тогда он гоняет тесты и чинит падения без подтверждения каждого шага.
claude -p "Прогони тесты и почини падения по TDD" \
--allowedTools "Bash,Read,Edit"Коротко
Bash, видит падение и чинит по ошибке.--allowedTools "Bash,Read,Edit" убирает лишние подтверждения в фоновом режиме.Часть 5 · Границы
TDD — не религия. Это инструмент под определённый класс задач: там, где у поведения есть чёткий вход и выход, тест окупается мгновенно. Там, где результат субъективен или одноразов, тест-первым только тормозит.
Пример
Делаешь функцию скидки: «при сумме от 5000 — минус 10%». Один тест: вход 5000 → результат 4500. Второй: вход 4999 → результат 4999 (скидки нет). Агент пишет оба теста, потом код. Граничный случай (4999 против 5000) ловится сразу — а это самое частое место ошибок.
Когда TDD не нужен
Не гоняй TDD на вёрстке, цвете кнопки и тексте — там результат оценивается глазами, тест бесполезен. Не пиши тесты на разовый скрипт, который запустишь один раз и удалишь. И не требуй покрытия «на 100% всего подряд»: тест нужен там, где поведение можно сломать незаметно, а не везде ради галочки.
Коротко
Вопросы
TDD (разработка через тесты) с Claude Code — это когда агент сначала пишет тест на ещё не существующее поведение, видит как тест падает, потом пишет минимальный код, чтобы тест прошёл. Цикл называется red-green-refactor: красный (тест падает), зелёный (тест проходит), рефактор (чистим код, не ломая тесты). Тест становится проверяемым контрактом, а не словами агента «вроде работает».
Тест, написанный до кода, фиксирует ожидаемое поведение и не подгоняется под уже готовую реализацию. Если дать агенту написать код, а потом тесты, он часто пишет тесты, которые просто повторяют то, что код уже делает, включая баги. Тест-первым задаёт цель: агент пишет ровно столько кода, сколько нужно, чтобы зелёный тест прошёл, и сразу видит результат запуском, а не на глаз.
Дай агенту команду запуска тестов в задаче и явно попроси прогнать её и показать вывод. Claude Code умеет сам вызывать тест-раннер через Bash, видеть падения и чинить код по реальной ошибке. В headless-режиме это включается флагом --allowedTools "Bash,Read,Edit" — тогда агент гоняет тесты без ручного подтверждения каждого запуска.
Да, TDD удобен новичку именно потому, что снимает вопрос «а оно вообще работает». Не нужно читать код глазами и доверять агенту на слово — зелёный тест это объективный сигнал, что поведение есть. Начни с простого: одна функция, один тест на её ожидаемый результат. Claude Code сам напишет и тест, и реализацию, а ты увидишь зелёную галочку как доказательство.
Читать дальше
Прикладной материал, разборы и рабочие приёмы — то, чем пользуюсь сам, без воды. Залетай, там самое полезное.
Зайти в Telegram