Генерация тестов моделью упирается в границу между покрытием и смыслом
Просьба «напиши тесты к этому модулю» даёт результат почти мгновенно и почти всегда зелёный. Тесты компилируются, покрытие растёт, отчёт выглядит убедительно. Проблема выясняется позже: такие тесты описывают текущее поведение функции, включая её ошибки.
Механика понятна. Модель видит реализацию и выводит ожидания из неё, а не из требований. Если в коде перепутан знак, тест зафиксирует перепутанный знак как правильный и заблокирует будущее исправление.
Что помогает вернуть смысл
Практика показывает, что результат резко меняется, когда модели дают не реализацию, а спецификацию — описание контракта, примеры из документации, формулировку бизнес-правила. Тесты становятся реже, но начинают ловить настоящие расхождения.
Второй рабочий приём — просить не примеры, а свойства: что должно оставаться верным при любых входных данных. Такие проверки хорошо ложатся на генеративное тестирование, и модель здесь сильна именно как источник гипотез, а не как исполнитель.
Наконец, часть команд использует модель наоборот — просят сломать код и предложить входные данные, на которых он упадёт. Этот режим не даёт готовых тестов, но исправно вскрывает края, о которых автор не думал.
Что это значит
Подробности и первичное описание опубликованы на странице разбор структуры запроса к генератору, там же собраны условия доступа и ограничения, о которых заявили разработчики.
Похожие материалы и обновления по теме мы собираем в разделе ИИ-агенты и автоматизация — он пополняется по мере выхода новых сообщений.