Попросите Claude Code показать тест, который падает при намеренной ошибке в коде и проходит после её исправления. Затем проверьте, что падение связано именно с неверным результатом, а не с настройками запуска. Так можно оценить тесты сайта или приложения после вайбкодинга, даже если вы не пишете код сами. Ниже разберём, как задать ожидаемое поведение, проверить чувствительность тестов к ошибкам и получить от разработчика отчёт, по которому можно принять работу.
Что должен проверять тест в бизнес-сценарии?
Начните с правила, которое вы можете объяснить без технических терминов. Например: покупатель применяет допустимую скидку, и итог заказа уменьшается; товар без остатка нельзя добавить в заказ; сотрудник без нужных прав не может изменить цену. Для каждого правила заранее запишите ожидаемый результат. Тогда у теста появится независимая точка отсчёта.
После вайбкодинга есть риск замкнутого круга: агент пишет функцию, затем читает её и создаёт тест, который подтверждает текущее поведение. Если в самой функции ошибка, она попадёт и в ожидания теста. Поэтому правило бизнеса нужно передать отдельно от реализации.
Для белорусского магазина с ценами в BYN это особенно наглядно на расчёте заказа. Владелец задаёт порядок применения скидки и правило округления, а разработчик переводит их в проверку. Ожидаемую сумму нужно получить независимо от функции, которую тестируют. Иначе одна и та же ошибка окажется по обе стороны сравнения.
Дайте Claude Code такое задание: «Сначала опиши ожидаемый результат по моему правилу. Не вычисляй его через функцию, которую собираешься проверять. Если правило допускает разные трактовки, задай вопрос до написания теста».
Как убедиться, что Claude Code запустил тесты?
Попросите показать точную команду запуска и её вывод. Фраза «тесты проходят» без следов выполнения не позволяет понять, запускал ли агент проверки, какие файлы выбрал и завершилась ли команда без ошибки.
В разборе Ofox все агенты из описанного сравнения верно назвали причину ошибки, но действовали по-разному: Codex CLI, OpenCode и Cline запустили тест перед ответом, а Claude Code, Reasonix и Pi ответили после чтения кода. Это наблюдение относится к конкретному сравнению, а не ко всем запускам этих инструментов. Для приёмки работы оно даёт полезный ориентир: верный диагноз ещё не доказывает, что проверка выполнялась (источник: Ofox, «Harness для AI-кодинга 2026»).
Harness — это окружение, через которое агент получает инструменты и выполняет действия. Сам выбор такого окружения не гарантирует запуск тестов. Закрепите требование в задании: «После изменения выполни подходящую команду тестирования. Если запуск невозможен, укажи причину и не называй результат успешным».
- Сверьте рабочую папку: команда должна выполняться в нужном проекте.
- Проверьте, что запуск включает тест нужного сценария.
- Посмотрите, нет ли пропущенных проверок: пропуск не подтверждает работу функции.
- Уточните версию кода: отчёт должен относиться к тем изменениям, которые вы принимаете.
Отсутствие доступа к тестовой базе или ошибка установки зависимостей означает, что результат пока неизвестен. Сначала нужно устранить препятствие, затем повторить запуск.
Как проверить тест намеренной ошибкой?
Проверяйте чувствительность теста в отдельной рабочей копии проекта или изолированном тестовом окружении. Рабочий сайт и реальные заказы для этого не подходят. До эксперимента сохраните исходное состояние, чтобы затем точно восстановить код.
Суть проверки проста: разработчик временно нарушает конкретное правило, а тест должен заметить последствия. Например, можно убрать применение скидки или разрешить действие пользователю без нужных прав. Менять следует только тот участок, поведение которого вы проверяете.
- Запустите нужный тест на исходном коде и зафиксируйте результат.
- Внесите одну намеренную ошибку в проверяемую логику.
- Повторно запустите тот же тест и сохраните причину падения.
- Восстановите исходный код.
- Повторите запуск, чтобы подтвердить возврат к успешному результату.
Тест на скидку должен упасть из-за неверной итоговой суммы. Если после правки файл перестал загружаться из-за опечатки, вы проверили только реакцию на сломанный код. Такой результат ничего не говорит о том, замечает ли тест ошибку в расчёте.
Этот подход называют мутационным тестированием: в программу вносят контролируемые изменения и смотрят, обнаружат ли их тесты. Начать можно вручную, с одного важного правила. Если тест остался зелёным, разберите причину: возможно, он не вызывает нужную функцию, использует неподходящие входные данные или вообще не сравнивает результат с ожиданием.
Отдельно проверьте подмены внешних сервисов, которые разработчики называют моками. Они помогают тестировать логику без настоящего запроса к сторонней системе. Но если подмена заменяет сам расчёт заказа готовым ответом, тест не проверяет расчёт. Попросите показать, где выполняется реальная логика, а где начинается подмена.
Какие доказательства запросить перед приёмкой?
Для каждого критичного сценария попросите короткую связку: правило бизнеса, файл теста, команда запуска и результат эксперимента с ошибкой. По ней проще обсуждать конкретный пробел. Большое количество тестов само по себе не показывает, что они защищают нужные функции.
В русскоязычном руководстве по Claude Code приведён тезис Anthropic: поиск проблем стало проще распараллеливать, а узкое место сместилось к проверке находок, расстановке приоритетов и исправлениям. В исходном контексте речь идёт о безопасности. Для приёмки тестов полезен тот же принцип: найденную проблему нужно подтвердить воспроизводимой проверкой (источник: GitHub, sfrangulov/claude-code-handbook-ru).
Попросите сохранить краткий отчёт рядом с проектом. В нём достаточно указать сценарий, ожидаемое поведение, намеренное нарушение и причину падения теста. Добавьте результат повторного запуска после восстановления кода. Скриншот зелёных отметок без этих сведений оставляет слишком много вопросов.
Если сайт обращается к серверу, отдельно проверьте весь путь действия. Тест функции расчёта не доказывает, что форма отправляет правильные данные и сервер сохраняет нужный результат. Для этого пригодится проверка сайта на ошибки в API и сохранении данных. В отчёте разделите то, что проверили внутри функции, и то, что проверили через пользовательский сценарий.
С безопасностью граница похожая: успешный тест одного ограничения доступа не подтверждает защищённость всего сайта. Если агент сообщает о найденной уязвимости, используйте отдельный порядок проверки отчёта Claude Code об уязвимостях, прежде чем считать находку доказанной.
При передаче проекта на независимое тестирование такую проверку можно включить в задание: какие правила проверить, как подтвердить обнаружение ошибки и какие материалы передать владельцу. Тогда результатом работы станет воспроизводимый отчёт с понятными границами проверки.
Типичные ошибки при проверке тестов Claude Code
- Доверять только зелёному статусу. Добавьте контролируемую ошибку и проверьте, что нужный тест её обнаруживает.
- Брать ожидаемый результат из проверяемой функции. Задайте его отдельно по правилу бизнеса.
- Менять несколько участков сразу. Вносите одну ошибку за эксперимент, иначе причину падения трудно установить.
- Проверять только успешное действие. Добавьте отказ: недопустимую скидку, отсутствие прав или неверный ввод.
- Просить агента исправить всё сразу после падения. Сначала выясните, верно ли ожидание, иначе агент может подогнать тест под ошибочное поведение.
Цикл «исходный код проходит — намеренная ошибка вызывает падение — восстановленный код снова проходит» подтверждает чувствительность теста к конкретному нарушению. Он не доказывает отсутствие остальных ошибок. Сохраняйте рядом с результатом название сценария и описание того, что именно проверили.
Сейчас за минуту запишите одно правило вашего сайта в формате: «Когда пользователь делает …, система должна …». Передайте эту фразу Claude Code как независимое ожидание для теста.
