ИИ-тесты не запускаются? Четыре «шлюза» в CI, которые ловят галлюцинации и тихие поломки
ИИ-тесты не запускаются? Четыре «шлюза» в CI, которые ловят галлюцинации и тихие поломки Модели пишут тестовый код быстрее, чем разработчики успевают его проверять. Автор предупреждает: без контроля такие тесты содержат галлюцинации — проверки несуществующей логики, уползают от ожидаемого поведения и допускают тихие регрессии, которые всплывают только в продакшене. Его ответ — не запрещать ИИ, а пропускать каждый сгенерированный тест через обязательные проверки перед слиянием. Суть подхода: сгенерированный тест считается недоверенными входными данными. В конвейере CI настраиваются четыре «шлюза»: тест обязан компилироваться и запускаться, повышать реальное покрытие кода, падать при изменении поведения и не проверять выдуманную логику. Первый шлюз — исполнение. ИИ-тесты нередко содержат синтаксические ошибки или вызывают несуществующие API; тест, который не запускается, не защищает вообще ни от чего. В GitHub Actions добавляется шаг, который просто запускает тесты на каждом push и pull request — слияние блокируется, если тесты не проходят. Второй шлюз — покрытие. Модель может выполнять код, не проверяя осмысленного поведения, поэтому автор требует, чтобы новые тесты поднимали покрытие строк и веток — например, через пороги в конфигурации Jest или проверку отчёта о покрытии в GitLab CI. Тест без роста покрытия, скорее всего, проверяет тривиальные или выдуманные пути. Самая сильная защита от галлюцинированных проверок — третий шлюз, мутационное тестирование: в код специально вносят изменения и смотрят, падают ли тесты. Тест, который «переживает» мутации, проверяет случайные детали, а не реальные правила работы. Инструмент вроде Stryker запускается в отдельном задании CI с порогами качества. Четвёртый шлюз — дрейф поведения. Тесты от ИИ могут закрепить неверные допущения, поэтому ожидаемые результаты фиксируются снимками (snapshot-тестирование) или approval-тестами. Если снимок изменился, слияние падает — пока разработчик явно не одобрит это изменение. Все шлюзы собираются в один конвейер и могут идти параллельно: pull request сливается только когда исполнение, покрытие, мутации и дрейф пройдены — иначе тесты отклоняются автоматически. Автор даёт практические оговорки. Мутационное тестирование заметно замедляет CI — его предлагают гонять по расписанию или для рискованных изменений, а обычные pull request держать на остальных шлюзах. Исследовательские тесты выводятся за рамки: проверки касаются только файлов, попадающих в репозиторий. Порог покрытия советуют начинать с низкого — например 50% — и поднимать постепенно. Для снимков и диффов требуется явное одобрение разработчика; сам автор считает, что шлюзы заменяют ручную проверку кода на предмет корректности, хотя просматривать сгенерированный код всё равно нужно. Итог автора: сгенерированные ИИ тесты — это инструмент ускорения, а не гарантия качества. С шлюзами недоверенный вывод превращается в проверенное покрытие, и разработка ускоряется без тихих регрессий в продакшене. Это описание методики с примерами конфигураций, а не отчёт о внедрении с измеренным эффектом. Источник: https://dev.to/tamizuddin/stop-letting-ai-write-tests-you-wont-run-enforce-sdlc-gates-that-catch-llm-hallucinations-drift-9ea