Как писать тесты с ИИ в критически важном коде

Я долго сопротивлялся идее, что нейросети смогут писать за меня тесты, ведь тест — это не просто код, а контракт и спецификация. Раньше я думал, что рутина написания тестов — это цена за качество, но теперь вижу: ИИ-агенты действительно способны невероятно ускорить этот процесс. Они берут на себя черновую работу, но, как показывает опыт, не снимают с нас, разработчиков, самую важную задачу — контроль качества и осмысление проверок. Если просто слепо копировать сгенерированное, то получишь ложное чувство безопасности.

Главный риск, который я обнаружил, работая с такими инструментами, как Claude Code, Cursor или JetBrains AI Assistant, заключается в «уверенном заблуждении». ИИ может быстро поднять покрытие до впечатляющих 90%, но в тестах часто оказываются бессмысленные или хрупкие ассёрты (проверки). Например, модель может проверить, что функция вернула объект, но не проверит, что внутри этого объекта лежат правильные бизнес-данные или что был вызван нужный метод. Мой опыт показывает, что ИИ — это великолепный ускоритель, но генерацию проверок для критически важной логики всегда нужно дорабатывать вручную.

Чтобы получить от агентов максимальную пользу, нужно научиться ими правильно управлять. Нельзя просто сказать «напиши тесты для этого класса». Я понял, что необходимо быть очень конкретным: нужно указать фреймворк, чётко запросить не только позитивные, но и негативные сценарии, а также табличные кейсы для граничных условий и исключений. Чем больше контекста мы дадим — сигнатуры, комментарии о контрактах и даже фикстуры, – тем стабильнее и релевантнее будут тесты.

Тест должен выполнять роль контракта, а не просто давать «галочку» покрытия. Высшая ценность теста проявляется при исправлении ошибок, когда он выступает «фильтром». Для этого мы должны убедиться, что тест падает до патча и проходит после его применения (метрика fail‑to‑pass). Агентные подходы, такие как SWT-Bench, показывают, что именно такие тесты, которые воспроизводят баг, могут повысить точность автоматического ремонта кода в два раза.

Не стоит забывать об итеративном цикле: генерация тестов — это только начало. После того, как агент предложил черновик, его необходимо запустить локально или в CI. Если тесты проходят, то мы их просматриваем, исправляя слабые или бессмысленные ассёрты. Если покрытие (например, ветвей) недостаточно, нужно использовать отчёты покрытия, чтобы «навести» агента на пропущенные участки кода и запросить регенерацию. Это постоянный цикл: сгенерировать → запустить → исправить → повторить для «дырок».

Итак, что в сухом остатке? ИИ-агенты стали неотъемлемой частью процесса, они радикально снижают стоимость создания черновиков. Но они не заменяют дисциплину, не заменяют TDD-принципы. Самая эффективная стратегия — это использовать ИИ как мощный инструмент для черновиков и покрытия рутинных путей, сохраняя за собой критическое мышление и ответственность за семантику, чтобы наши тесты действительно что-то значили.

Подробнее об ИИ инструментах, которые позволили попасть в топ 5% лучших сотрудников Яндекса, рассказываю тут: