Топ 6 ИИ для написания тестов
Шесть ИИ-инструментов, которые пишут тесты: от агентов в терминале, которые сами запускают прогон и чинят падения, до генератора, который делает это без участия человека. Разбираем, какие тесты у них получаются, где они закрепляют баги как норму и как проверять то, что они написали.
Какие тесты умеет писать ИИ
Тест — самая благодарная задача для ИИ: у него понятная форма, короткий цикл проверки и объективный результат. Модель хорошо перебирает граничные случаи, о которых человек забывает, — пустые коллекции, отрицательные числа, строки с пробелами, конец месяца, — и не устаёт писать однотипные проверки для десятка похожих методов. Что она делает плохо: не знает, каким поведение должно быть. Если попросить «напиши тесты на эту функцию», агент зафиксирует то, что функция делает сейчас, включая баг, и с этого момента баг защищён зелёным прогоном.
Поэтому мы сравнивали не «сколько тестов напишет», а другое: запускает ли инструмент тесты сам и реагирует ли на падение, пишет ли по описанию намерения или только по существующему коду, помогает ли перечислить поведения до написания проверок, с какими языками работает, и насколько велик риск, что вместо кода он поправит тест. Подходы к тестированию — модульные, интеграционные, контрактные — мы разбирали в подборке подходов к тестированию кода; здесь речь только о том, кто и как их пишет.
Общее правило: тест, написанный ИИ, читают так же внимательно, как код. Тест, который проверяет, что заглушка вернула то, что в неё положили, выглядит как тест, считается в покрытии и не ловит ничего. Доступность зарубежных сервисов и оплату стоит проверять на сегодня: часть из них недоступна без ухищрений.
Топ 6 ИИ для написания тестов
Claude Code
агент, который пишет тест, запускает его и разбирается, почему упал
Claude Code работает в терминале, видит проект целиком и замыкает цикл: пишет тест, запускает команду прогона, читает вывод, исправляет. Команда для запуска тестов и правила оформления кладутся в файл CLAUDE.md, и агент пользуется ими в каждой сессии. Работает на моделях Claude 5 (Opus 5, Sonnet 5, Fable 5) и Haiku 4.5; для тестов часто хватает облегчённой модели, для разбора сложного падения полезна старшая.
Почему на первом месте. Агент умеет сначала перечислить, какие поведения стоит проверить, обсудить список и только потом писать, а это ровно тот порядок, в котором тесты получаются осмысленными. Он читает существующие тесты и повторяет их стиль, а не приносит свой. При падении он способен объяснить, что именно упало и в чём расхождение с ожиданием, — часто это ценнее самого теста.
Минусы. Платный, и большой набор тестов на старом модуле обходится заметно. Главная опасность — соблазн «починить» падающий тест, подогнав ожидание под фактический результат: без явного запрета в правилах агент иногда так и делает. Любит заглушки: если не ограничить, замокает всё вокруг и тест перестанет что-либо проверять. Доступность и оплату из России стоит проверить.
- Замкнутый цикл: написал, запустил, исправил
- Сначала список поведений, потом код
- Повторяет стиль существующих тестов
- Платный, старые модули дороги
- Может подогнать тест под результат
- Склонен к избыточным заглушкам
лучший агент для тестов с настоящим прогоном и разбором падений · оценка 9,5
GitHub Copilot
тесты прямо в редакторе — для функции под курсором
Copilot пишет тесты там, где вы уже работаете: в VS Code, в средах JetBrains и других редакторах. Выделили функцию — попросили тесты — получили файл в принятом в проекте фреймворке. В агентном режиме он способен запустить прогон и поправить то, что не собралось. Инструкции для проекта — какой фреймворк, как называть тесты, что не мокать — кладутся в файл инструкций Copilot, общий для редактора, терминала и ревью.
Почему второе место. Самый короткий путь от «надо бы покрыть» до первого теста: не нужно переключаться в терминал и объяснять контекст, редактор уже знает открытый файл и соседей. Для ежедневной работы — новая функция, три теста, коммит — этого достаточно, и разработчики действительно начинают писать тесты, а не откладывать.
Минусы. Нужна подписка. Тесты в базовом режиме поверхностны: основной сценарий и один-два очевидных граничных случая, без неудобных вопросов о поведении при ошибке. Без запуска они иногда не собираются — неверный импорт, устаревшая сигнатура. Copilot охотно дублирует существующие тесты, если не видел их. Доступность подписки стоит проверить.
- Тесты без выхода из редактора
- Знает открытый файл и фреймворк проекта
- Агентный режим запускает прогон
- Только по подписке
- Поверхностные сценарии по умолчанию
- Дублирует то, чего не видел
лучший способ писать тесты каждый день, не выходя из редактора · оценка 9,2
Qodo
расширение, которое сначала перечисляет поведения, а потом пишет тесты
Qodo вырос из проекта, который занимался именно тестами, и это видно. Расширение для редактора разбирает функцию, выводит список поведений — «возвращает пустой результат при пустом вводе», «бросает исключение при отрицательном значении», — и предлагает написать тест на каждое. Тесты запускаются прямо из панели, падения видны сразу, недостающие поведения можно добавить словами. Есть бесплатный уровень с ограничениями.
Почему полезен. Список поведений — правильная точка входа: он заставляет думать, что функция должна делать, до того как код зафиксирован тестом. Для старого модуля без тестов это ещё и быстрый способ понять, что он вообще делает. Рядом есть инструмент для ревью pull request, и вместе они закрывают «написали — проверили — обсудили».
Минусы. Линейка продуктов запутана, названия менялись, и с первого раза непонятно, что ставить. Расширение тяжёлое и заметно нагружает редактор. Поддержка языков неровная: для популярных стеков всё хорошо, для редких — набор возможностей меньше. Предложенные поведения многословны, и часть из них — очевидности, которые приходится вычёркивать.
- Список поведений до написания кода
- Запуск и падения в одной панели
- Есть бесплатный уровень
- Запутанная линейка продуктов
- Тяжёлое расширение
- Неровная поддержка языков
лучший инструмент, чтобы сначала перечислить поведения, а потом их проверить · оценка 9,0
Codex CLI
открытый терминальный агент, который гоняет тесты в песочнице
Codex CLI — открытый агент от OpenAI, который читает репозиторий, пишет тесты и запускает их внутри песочницы, где запись ограничена рабочей папкой. Инструкции для проекта — команда прогона, фреймворк, что считать готовым — кладутся в файл AGENTS.md. Режимы подтверждения позволяют дать агенту свободу на тестах и оставить контроль над правками основного кода.
Почему в подборке. Песочница — хорошее место для тестов: агент может сколько угодно запускать прогон, не имея возможности задеть что-то за пределами проекта. Разделение прав по режимам позволяет честно сказать «тесты пиши сам, код не трогай», и это снижает риск, что падение будет «исправлено» правкой того, что тестируется.
Минусы. Аккаунт OpenAI, доступность и оплату проверять. Песочница по умолчанию отрезает сеть, и интеграционные тесты, которым нужна база или внешний сервис, в ней не проходят — приходится настраивать. Агент часто останавливается и переспрашивает, что для тестов скорее раздражает, чем защищает. Тесты по существующему коду фиксируют текущее поведение, как и у всех.
- Песочница и раздельные права на код и тесты
- Открытый код, файл инструкций
- Прогон в замкнутом цикле
- Только OpenAI, доступ проверять
- Без сети интеграционные тесты не идут
- Часто останавливается и переспрашивает
лучший вариант, чтобы дать агенту свободу на тестах и ограничить на коде · оценка 8,9
Gemini CLI
открытый агент с большим контекстом и бесплатным уровнем
Gemini CLI читает модуль вместе со всеми существующими тестами, что важно: тесты получаются в том же стиле, с теми же вспомогательными функциями и фикстурами. Агент запускает прогон, правит падения, ходит в интернет за документацией фреймворка. Контекст проекта описывается в файле GEMINI.md, для личного аккаунта Google есть бесплатный уровень с ограничениями.
Почему полезен. Большой контекст модели позволяет скормить агенту крупный модуль с зависимостями целиком и попросить тесты на всё, что там есть, — для старого кода без покрытия это быстрый старт. Для знакомства с агентами, которые пишут тесты, планка входа самая низкая: не нужно ничего покупать.
Минусы. Лимиты бесплатного уровня заканчиваются как раз на большом модуле. Агент пишет много: десятки тестов там, где нужны пять осмысленных, и переписывает существующие файлы, если не попросить их не трогать. Многословные объяснения замедляют работу. Доступность сервисов Google и оплату проверять заранее.
- Видит модуль и существующие тесты целиком
- Бесплатный уровень для старта
- Открытый код и запуск прогона
- Лимиты кончаются на больших модулях
- Пишет слишком много тестов
- Может переписать существующие файлы
лучший бесплатный старт для тестов на крупном модуле · оценка 8,7
Diffblue Cover
генератор модульных тестов для Java, который работает без диалога
Diffblue Cover устроен иначе, чем остальные: это не чат и не агент, а программа, которая берёт Java-проект, анализирует классы, генерирует модульные тесты и сама проверяет, что они компилируются и проходят. Запускается из командной строки, из сборки или как расширение для IntelliJ. Производитель подчёркивает, что генерация не опирается на языковую модель, поэтому тесты не «выдумывают» несуществующие методы. Есть бесплатная версия для отдельных разработчиков с ограничениями.
Почему в подборке. Для большого старого Java-проекта без тестов это единственный в списке способ получить базовое покрытие за часы, а не недели, — и это покрытие действительно проходит. Дальше на такой сетке безопаснее рефакторить: любое изменение поведения сразу видно.
Минусы. Только Java. Тесты фиксируют текущее поведение целиком, включая баги: это характеризационные тесты, а не проверка намерения, и читать их как спецификацию нельзя. Читаемость посредственная — сгенерированные имена и наборы значений выглядят механически. Для команды инструмент платный, и на сложных зависимостях доля классов, для которых тесты не сгенерировались, бывает заметной.
- Тесты компилируются и проходят без диалога
- Базовое покрытие старого проекта за часы
- Не выдумывает методы
- Только Java
- Закрепляет текущее поведение вместе с багами
- Механические имена, платно для команды
лучший инструмент для сетки характеризационных тестов в старом Java-проекте · оценка 8,4
Сравнение по главному
| Инструмент | Где работает | Что делает лучше всего | Главный минус |
|---|---|---|---|
| Claude Code | терминал, любой стек | цикл с прогоном и разбор падений | платный, может подогнать тест |
| GitHub Copilot | редактор, любой стек | тесты без переключения контекста | поверхностные сценарии |
| Qodo | редактор, популярные стеки | список поведений до кода | тяжёлое расширение |
| Codex CLI | терминал, песочница | раздельные права на код и тесты | без сети нет интеграционных тестов |
| Gemini CLI | терминал, любой стек | крупный модуль целиком, бесплатно | пишет слишком много |
| Diffblue Cover | командная строка, IntelliJ | покрытие Java без диалога | закрепляет баги как норму |
Как получить тесты, которым можно верить
Сначала поведение, потом тесты. Не «напиши тесты на функцию», а «функция должна возвращать пустой список при пустом вводе и бросать ошибку при отрицательном лимите — напиши тесты на это». Иначе агент честно зафиксирует то, что есть, и баг получит защиту. Если поведение неизвестно, попросите сначала перечислить, что функция делает, и проверьте список глазами.
Запретите чинить тест ради зелёного прогона. В файл правил проекта стоит записать явно: если тест падает, агент объясняет расхождение и ждёт решения, а не подгоняет ожидаемое значение. Это самая частая ошибка агентов и самая дорогая, потому что её не видно в прогоне.
Читайте тесты. Тест с заглушкой на всё, кроме одной строки, тест без утверждений, тест, который проверяет, что заглушка вернула подложенное значение, — всё это считается в покрытии и не ловит ничего. Покрытие показывает, какие строки выполнялись, а не что было проверено.
Сломайте код и посмотрите. Самая быстрая проверка теста — намеренно испортить поведение, которое он должен ловить, и убедиться, что он упал. Если не упал, тест бесполезен, каким бы аккуратным он ни выглядел.
Не подкладывайте настоящие данные. Реальные записи клиентов, выгрузки из боевой базы и чужие документы не должны попадать в фикстуры, которые уходят в сторонний сервис и остаются в репозитории. Для старого кода, где тесты ещё и способ понять, что он делает, пригодятся способы разобраться в чужом коде.
Частые вопросы
Стоит ли генерировать тесты для старого кода без покрытия?
Да, но с пониманием, что это характеризационные тесты: они фиксируют то, что код делает сейчас, включая ошибки. Их польза — в защите от случайных изменений поведения при рефакторинге. Как спецификацию их читать нельзя, и каждый найденный баг должен сопровождаться правкой теста, который его защищал.
Почему агент чинит тест вместо кода?
Потому что его задача — зелёный прогон, и подогнать ожидание проще, чем найти причину. Лечится правилом в файле проекта: при падении сначала объяснение, потом решение человека. И привычкой читать diff теста так же, как diff кода: изменение ожидаемого значения — это всегда вопрос «почему».
Можно ли доверять показателю покрытия?
Только как карте того, куда тесты не заходят вообще. Высокое покрытие с бессмысленными утверждениями не ловит ничего. Полезнее смотреть, падают ли тесты при намеренной поломке кода, и есть ли проверки на ошибки и граничные случаи, а не только на основной сценарий.
Что выбрать для Java-проекта?
Для быстрой защитной сетки на старом коде — Diffblue Cover, он даёт проходящие тесты без диалога. Для новых модулей и осмысленных проверок по намерению — агент вроде Claude Code или Copilot в редакторе. Разумно сочетать: сетка защищает от регрессий, агент пишет тесты, которые объясняют, что код должен делать.
Итог
Claude Code лидирует за замкнутый цикл: список поведений, тест, прогон, разбор падения. Copilot в редакторе — выбор для ежедневных тестов на новую функцию без переключения контекста, Qodo — для тех, кому важно сначала увидеть список поведений. Codex CLI удобен, когда нужно дать агенту свободу на тестах и ограничить на коде, Gemini CLI — бесплатный старт на крупном модуле, Diffblue Cover — защитная сетка для старого Java.
Какой бы инструмент вы ни взяли, тест — это утверждение о том, каким должно быть поведение, и это утверждение делает человек. Опишите поведение до генерации, запретите подгонять ожидания, прочитайте тесты, сломайте код и убедитесь, что они падают.
Комментарии
0Будьте первым, кто ответит автору.