AI-генерация unit-тестов: автоматическое покрытие кода

AI-генерация unit-тестов: где ломается покрытие

Строковое покрытие врёт: отчёт показывает 80%, а на релизе падают сценарии, которых в нём не видно. Метрика считает исполненные строки, а не пройденные ветки логики — ранние выходы, тернарники, блоки обработки исключений остаются без проверок. Это и есть узкое место покрытия: цифра растёт, уверенность перед выкаткой — нет.

Отдельная зона просадки — правки в старом коде. Изменение добавляет одно условие, общий процент не двигается, а новая ветка не проверена ничем. Порог на новый код в SonarQube считает покрытие по изменённым строкам — там сразу видно, что автоматическое покрытие кода отстаёт от темпа правок, а регрессии при релизе приходят из дельты, а не из легаси.

Третья зона — обработка ошибок: таймауты, повторы, частичные отказы внешних сервисов, пустые и невалидные ответы. Воспроизводить их руками долго и неудобно, поэтому их чаще всего и обходят стороной — а срабатывают в проде именно они.

Четвёртая — интеграционные стыки: сериализация, контракты между сервисами, маппинг между слоями и хранилищем. Тесты внутри модуля зелёные, а на стыке расходится формат поля или теряется пустое значение. Ниже разбираем, как AI-генерация unit-тестов закрывает эти четыре места по шагам.

Что меняется после внедрения: покрытие, ревью, отказы

Первый эффект виден на шлюзе качества по новому коду. Сгенерированные тесты появляются в том же изменении, что и логика, поэтому покрытие не «подтягивают» отдельной задачей спустя месяц: доля проверенных строк в самом изменении растёт с трети до 70–80% вместо размытого среднего по репозиторию. Метрику видно в SonarQube рядом с остальными показателями сборки, так что рост покрытия кода — не отчёт, а измеримое условие прохождения сборки.

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

Третье — класс отказов, который перестаёт доходить до стенда и продакшена. Регрессии после точечных правок ловятся на этапе сборки: проверка на границе модуля краснеет до выкладки, а не в дежурную смену. Доля откатов в релизном цикле падает, и стабильность релизов перестаёт зависеть от того, кто именно сегодня на связи.

Оговорка, без которой эффект не держится: тесты должны быть сопровождаемыми. Мы генерируем их на каждое изменение, а не «на весь проект разом», не дублируем пересекающиеся сценарии и не привязываем проверки к деталям реализации — иначе через пару месяцев их удаляют, и покрытие возвращается на исходный уровень.

Сравнение режимов: локальный запуск, конвейер, выделенный контур

Три режима запуска различаются не качеством генерации, а тем, где работает модель и куда уходит исходный код. Локальный запуск держит код на машине разработчика, конвейер сборки генерирует тесты на каждое изменение, а выделенный контур разворачивается внутри вашей сети и обслуживает сразу несколько репозиториев.

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

Этапы внедрения: от аудита кодовой базы до передачи

Внедрение генерации тестов начинается не с инструмента, а с разметки кодовой базы: где автоматические проверки дадут смысл, а где упрутся в скрытые зависимости и побочные эффекты. Порядок работ одинаков и для монолита, и для набора сервисов — меняется только объём аудита.

1. Аудит кодовой базы. Размечаем модули по связности, доле ветвлений и наличию явных контрактов. Отдельно помечаем код с внешними вызовами и глобальным состоянием — там генерация требует ручной настройки заглушек.

2. Схема покрытия. Расставляем приоритеты: критические пути, обработчики ошибок, граничные значения. Для каждого блока фиксируем целевой показатель покрытия, чтобы результат измерялся, а не обсуждался на вкус.

3. Настройка правил генерации. Задаём шаблоны, стиль именования, структуру файлов и используемый фреймворк тестирования. Прописываем, какие зависимости подменяются, а какие проверяются на реальных данных, и что не покрывается автоматически принципиально.

4. Проверка на выборке модулей. Прогоняем генерацию на 10–20 репрезентативных модулях и сравниваем с тестами, написанными вручную. Смотрим долю проходящих с первого запуска и время, которое ревьюер тратит на один сгенерированный тест.

5. Встраивание в контур разработки. Генерация запускается на изменённых файлах, тесты проходят тот же ревью, что и ручные, а падение проверок блокирует слияние ветки.

6. Передача документации и обучение. Отдаём описание правил, конфигурации и разбор спорных случаев. Проводим разборы на реальных модулях, чтобы инженеры могли менять правила генерации сами, без нашей поддержки.

Критерий завершения этапа — команда добавляет новый модуль в схему покрытия и получает осмысленные тесты без участия подрядчика.

Что остаётся у команды: конфигурации, схемы, регламенты

Генерация unit-тестов живёт в репозитории, а не в нашем аккаунте. После сдачи у команды остаются настройки, карта покрытия, правила отбора модулей, документация и регламент сопровождения — без этого набора решение держится до первой крупной правки архитектуры, дальше тесты устаревают, исключения копятся, прогон перестают читать.

• Конфигурации генератора тестов — пороги покрытия по модулям, правила исключений (сгенерированный код, миграции, обёртки внешних сервисов), режимы прогона. Порог для отдельного модуля меняется без нашего участия.
• Карта покрытия модулей — по каждому модулю: какие ветки закрыты, где проверен только успешный сценарий, где разрыв. Перестраивается на каждом прогоне, а не руками раз в квартал.
• Правила отбора модулей — критерии попадания в генерацию: сложность ветвления, частота правок, место в цепочке вызовов. Приоритеты пересматриваются по мере роста кода.
• Регламент обновления тестов — что делать, когда сгенерированный тест упал: обновить ожидание, зафиксировать дефект или занести в исключения. С ответственным и порядком действий.
• Документация по тестам — запуск локально и в сборке, состав наборов, чтение отчёта о покрытии. Новый инженер входит в контур без переписки с нами.
• Передача решения — доступы к репозиторию тестов и настройкам прогона, разбор на живом модуле, перечень проверок перед первым самостоятельным изменением. Прогон и правку команда делает при нас.

Кейс: унаследованный сервис — покрытие выросло втрое

Унаследованный сервис расчётов жил в боевой эксплуатации около девяти лет: тесты писались точечно, часть из них разошлась с кодом и была отключена. Любая правка в старом модуле означала ручной прогон сценариев на стенде, а регресс всплывал уже после выката.

Точка отсчёта

Покрытие ветвей держалось на 18%, причём JaCoCo считал его только по модулям, где тесты вообще сохранились — остальное оставалось непрозрачным. На стенде стабильно фиксировали 18–22 отказа в неделю, а восстановление после правки в старом модуле занимало 4–5 часов, из которых больше половины уходило на локализацию причины.

Что изменили и что получили

Сначала статический анализ ранжировал модули по частоте правок и связности — генерация пошла туда, где цена регресса максимальна. Модель предложила тесты по сигнатурам, типам возврата и ветвлениям, мутационная проверка отсеяла наборы, проходящие на любой реализации, а инженер утвердил только те, что проверяют контракт модуля, а не его текущее поведение.

Внешние вызовы заменили записанными ответами, поэтому набор стал детерминированным и перестал зависеть от стенда. Покрытие ветвей выросло до 56%, число отказов на стенде упало до 5–7 в неделю, а время восстановления после правок в старом модуле сократилось до 40–50 минут.

Что делать, если кодовая база уже покрыта устаревшими тестами?

Унаследованное покрытие почти всегда формально: либо прогон красный и его научились игнорировать, либо зелёный, но проверяет не поведение, а детали реализации. Доверие к прогонам падает до нуля — регрессии всплывают в проде, а изменения катятся «на глаз». Разбираем, в каком порядке перебирать такой набор.

Сначала инвентаризация и три корзины: тесты, падающие при намеренной поломке логики; тесты, привязанные к реализации — приватные методы, порядок вызовов, точные снимки; и нестабильные, зависящие от среды или порядка запуска. Ориентир — не процент покрытия, а доля тестов, реагирующих на внесённую ошибку.

Дальше отделяем ценность от обвязки. Сценарии, тестовые данные и граничные значения, собранные из прошлых дефектов, переносим — это самый дорогой актив набора. Переписываем обвязку: запуск, изоляцию данных, подготовку окружения — именно из-за неё старый набор краснеет на неизменённом коде.

Порядок пересборки: сначала стабилизируем прогон — нестабильные тесты уходят в карантин с владельцем и сроком, но не удаляются молча. Затем закрываем критичные пути: права доступа, расчёты, миграции данных. И только потом расширяем покрытие, генерируя тесты от актуального поведения кода.

Доверие к прогонам держится на правиле: красный результат блокирует слияние, зелёный означает «поведение не изменилось». Поэтому тесты детерминированы — изолированные данные, фиксированное время, никаких сетевых обращений. Тогда набор растёт за счёт удаления дублей, а не времени прогона.

Частые сомнения: качество, ложные срабатывания, поддержка

Сомнения перед внедрением обычно сводятся к четырём вопросам: формальны ли сгенерированные проверки, не начнёт ли сборка падать на ровном месте, не утечёт ли исходный код и кто отвечает за набор после ухода автора. Каждое из них проверяется измеримо, а не заверениями.

Главной метрикой считаем не долю покрытых строк — её легко набрать проверками, которые ничего не проверяют, — а мутационную устойчивость и долю нестабильных прогонов.

Откуда берутся ложные срабатывания и как вы их убираете?

Источник большинства ложных падений — недетерминизм: время, случайные значения, порядок обхода коллекций, внешние сервисы. Генераторы фиксируются зерном, время и сеть подменяются управляемыми двойниками, данные готовятся в изолированной базе и откатываются после прогона. Проверка воспроизводится одинаково у разработчика и в сборочном контуре.

Код уходит на внешние серверы?

Разворачиваем внутри вашего контура: модель работает на ваших мощностях, исходники и история изменений не покидают периметр, исходящие обращения закрываются на уровне сети. Доступ — по вашим ролям, артефакты и журналы остаются у вас, а каталоги, которые нельзя показывать даже локальной модели, исключаются политикой.

Что с сопровождением, когда авторы уйдут с проекта?

Набор проверок устаревает при рефакторинге и требует владельца. Передаём регламент обновления и удаления проверок, состав метрик и точки контроля в сборочном контуре — команда ведёт набор сама. По желанию остаёмся на сопровождении с фиксированным сроком реакции на падения.

Обсудим задачу: что нужно от вас для старта

Чтобы вернуться с оценкой и планом работ, а не с общими словами, нам нужен контекст о коде и процессе разработки. Ниже — входные данные для оценки: чем больше пунктов закрыто, тем точнее сроки и тем меньше уточнений на старте проекта.

• Репозиторий или его часть, которую планируем покрывать: язык, фреймворк, структура модулей и точек входа.
• Что уже есть: существующие тесты, чем запускаются, текущее покрытие — какие ветки логики проверены, а какие нет.
• Как собирается проект: команда сборки, время полного прогона тестов, чем считаем покрытие.
• Ограничения по доступам: можно ли выгружать фрагменты кода во внешние сервисы или генерация идёт только внутри вашего контура.
• Требования к проверкам: какие сценарии обязательны, где вместо реальных зависимостей допустимы подставные объекты.
• Критерий приёмки: какая доля покрытия и какие модули считаются закрытыми, кто это подтверждает.
• Порядок работы с кодом: куда вносим изменения, кто ревьюит, нужна ли автоматическая проверка на каждом слиянии.

Этого достаточно, чтобы мы вернулись с оценкой и планом работ: объём, этапы, зона ответственности на вашей стороне и порядок запуска генерации тестов. Опишите задачу в свободной форме — обсудим детали и предложим формат старта.