Агент пишет тесты с теми же ошибками, что и код — как это ловить

Агент пишет патч, пишет для него тесты, выполняет их и сообщает об успехе. Дифф выглядит здраво, проверка пройдена. Но реализация может согласовываться с тестами, потому что в обоих местах содержится одна и та же ошибка. Если агент недопонял требования при написании кода, это непонимание может сохраниться и при чтении кода для получения ожидаемого результата.

Автор перевода на «Хабре» предлагает просить агента показывать поведение, от которого страхует тест, вероятную неисправную версию, которую тест отклонит, и откуда берётся ожидаемый ответ. Последнее не менее важно, чем демонстрация возможности провалить тест.

Пример с доставкой

Рассмотрим функцию расчёта стоимости доставки: если заказ стоит менее 5000 центов, доставка стоит 500 центов, если 5000 и более — бесплатно. В коде используется условие total_cents >= 5000. Тесты проверяют значения 4999 и 5001, обе ветки выполняются. Но если заменить >= на >, оба теста по-прежнему проходят — а клиент, заказавший ровно на 5000 центов, заплатит за доставку вопреки политике.

Чтобы ухватить разницу, нужно добавить проверку shipping_fee(5000) == 0. При правильной реализации тест проходит, при изменённой — нет. Так можно указать на требование и объяснить, почему отказ важен.

Что показало исследование

В июле 2026 года вышел препринт, в котором Майкл Константиноу, Флориан Тамбон и Майк Пападакис сравнили генерацию тестов в пяти моделях и проверили их на трёх бенчмарках на Python. Модели предлагалась дефектная реализация, и модель обнаруживала около 14% отказов. Тесты, сгенерированные из свежего контекста на основе описания задачи, отлавливали около 25%.

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

Мутационное тестирование

Элементарный пример мутационного тестирования — изменить оператор сравнения, прогнать тесты и посмотреть, отловят ли они изменение. Выживший мутант — повод изучить тесты подробнее. Идею описали Ричард ДеМильо, Ричард Липтон и Фредерик Сэйуорд ещё в 1978 году.

В Meta этот подход сочетают с большими языковыми моделями. Система ACH начинает с инженерной проблемы, генерирует имитации отказов, ускользающие от имеющихся тестов, после чего просит модель написать тест, который проходит на оригинальном коде и не проходит на изменённом. Затем система отфильтровывает предложенные изменения и отправляет тесты на ревью.

При оценке на Android Kotlin 277 из 571 антимутантных тестов (около 49%) не добавили ни строки тестового покрытия — они находили различия, уже охваченные тестами. Фильтр, требующий покрытия новой строки, отбрасывал бы такие тесты.

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