ИИ писал тесты за меня 30 дней: покрытие выросло с 38% до 71%. Разбор эксперимента и его ловушек
Разработчик провёл 30-дневный эксперимент: доверил генерацию тестов открытому ИИ-инструменту the-agent и получил прирост покрытия кода с 38% до 71% без единого теста, написанного вручную. Разбираемся, как это работает, где подвох и стоит ли повторять.
30 дней, ни одного теста вручную, покрытие с 38% до 71% — звучит как мечта любого разработчика. Но за красивыми цифрами скрываются ловушки, о которых молчат маркетологи.
Предыстория: боль, которую хотят вылечить
Суть эксперимента изложена в публикации на dev.to — открытом блоге для разработчиков, где любой может опубликовать свой опыт. Это важно: мы имеем дело не с научным исследованием и не с отчётом крупной компании, а с личным кейсом одного разработчика. Относиться к цифрам стоит с соответствующей долей скепсиса.
Автор описывает типичную проблему: после изменения одной сигнатуры функции сломались 35 тестов. Починка заняла полдня. Причём боль — не в написании тестов, а в их поддержке: нормальные входы, граничные случаи, ветки ошибок, а главное — ложное чувство безопасности, когда всё «зелёное», а критические пути не покрыты.
Для эксперимента был выбран инструмент the-agent — открытый ИИ-агент на GitHub, который генерирует, запускает и поддерживает тесты на основе текстовых описаний на естественном языке.
Как это устроено
Установка стандартная для npm-пакетов:
npm install -g the-agent
the-agent init --project ./my-app --language typescript
Конфигурационный файл позволяет задать целевой процент покрытия, фреймворк тестирования и заметки о совместимости с легаси-кодом. Автор использовал Vitest для TypeScript-проекта.
Принцип работы — вы описываете на естественном языке, что должна делать функция, а инструмент генерирует набор тест-кейсов. В примере из статьи описание «calculateTotal получает массив товаров, считает итог, поддерживает скидку по купону 100 от 200» дало тесты на обычные суммы, пустые массивы, пороговые значения скидок, наложение купонов и исключения для отрицательных цен.
Интеграция с CI: ключевой нюанс
Автор подчёркивает важный архитектурный момент: инструмент работает в режиме патчей, а не перегенерации всего набора тестов. Это значит, что при открытии pull request генерируются тесты только для изменённых файлов.
Интеграция через GitHub Actions: при каждом PR запускается the-agent с флагом --diff, который анализирует разницу между ветками. Время выполнения — 5–8 минут на PR. Результат — отчёт в формате JSON и автоматический «ворота» покрытия, которые блокируют мерж, если показатель ниже заданного порога.
Это, пожалуй, самый интересный технический элемент во всей истории: патчевый подход снижает время генерации и делает процесс инкрементальным.
Результаты
Сухие цифры за 30 дней:
- Покрытие: 38% → 71%
- Время на тесты для новой фичи: с половины дня до ~40 минут (включая ревью)
- Регрессии, пойманные CI: 3 штуки, которые иначе ушли бы в прод
- Удалено избыточных тест-кейсов: ~40%
Стоит ли верить цифрам
Здесь нужно сделать паузу. Автор публикует результаты на платформе, где нет обязательной проверки. Мы не знаем размер кодовой базы, сложность бизнес-логики, исходное состояние тестов и насколько агрессивно автор ревьюил сгенерированные тесты.
Покрытие кода — метрика, которую легко «раздуть». Вспомните классическую шутку: 100% покрытия не гарантирует ни одного полезного теста. Прыжок с 38% на 71% может означать как реальное улучшение, так и массовое появление формальных тестов, которые проверяют не то, что нужно.
Три пойманных регрессии за месяц — это убедительно, но выборка слишком мала для выводов.
Четыре ловушки, которые честно описаны
Автор заслуживает уважения за то, что не стал замалчивать проблемы. Вот основные:
1. Неточное описание — неправильные тесты. Если забыть упомянуть асинхронный шаг, инструмент сгенерирует синхронные тесты, которые пройдут ложно. ИИ не читает мысли — он работает с тем, что ему дали.
2. Конфликты с легаси-кодом. Инструмент генерирует тесты «по лучшим практикам», которые могут не совпадать со старыми форматами данных. Решение — явно описывать ограничения в конфигурации через поле compatibilityNotes.
3. Проблемы с асинхронностью. Таймеры, колбэки, внешние вызовы — инструмент периодически пропускает тайминговые моменты. В конфиге есть флаг asyncDetection, но он помогает не во всех случаях. Асинхронные тесты стоит проверять вручную.
4. ИИ не думает за вас. Инструмент гарантирует, что тесты запустятся, а не что бизнес-логика правильная. Ошибочное описание — уверенно неправильные тесты. Автор сформулировал рабочее правило: «ИИ генерирует, я проверяю семантику».
Кому это реально полезно
Разработчики, которые тратят время на поддержку тестов — здесь выгода очевидна: инструмент берёт на себя рутину обновления тестов при рефакторинге.
Тест-инженеры — хороший инструмент для разведывательного покрытия, но бизнес-логику нужно контролировать самостоятельно.
Те, кто ищет «установил и забыл» — не ваш случай. Инструмент требует настройки, написания качественных описаний и обязательного ревью результатов.
Контекст: рынок ИИ для тестирования
Эксперимент попадает в тренд последних двух лет: всё больше инструментов пытаются автоматизировать написание тестов с помощью языковых моделей. GitHub Copilot давно умеет генерировать тесты из контекста, Amazon CodeWhisperer предлагает аналогичные функции, а десятки стартапов строят целые платформы вокруг «ИИ-тестирования».
the-agent выделяется тем, что работает как автономный агент, а не как подсказки в IDE. Он интегрируется в CI-пайплайн и работает автоматически при каждом PR — это не просто «помощь при написании», а полноценный участник процесса.
Но ключевой вопрос остаётся открытым: генерация тестов — это не то же самое, что понимание того, что нужно тестировать. Ни один инструмент пока не заменяет инженерного мышления при проектировании тестовой стратегии.
Итог
Эксперимент показывает, что ИИ-агенты действительно могут ускорить рутинную работу по написанию и поддержке тестов. Патчевый подход с интеграцией в CI — продуманная архитектура, а честное описание ловушек делает публикацию полезной.
Но не стоит воспринимать «с 38% до 71%» как гарантию. Результат сильно зависит от качества описаний, сложности проекта и, главное, от того, насколько тщательно вы ревьюите сгенерированные тесты. Инструмент — бесплатный и открытый, так что проверить на своём проекте порог входа невысокий.
Начинать стоит с одного модуля, а не с всего проекта. И помнить: автоматизация тестирования экономит время, но не отменяет необходимости понимать, что именно вы тестируете.