TL;DR
Агент для кода пишет много валидных тестов, но слабых. Почти все они проходят на эталонной реализации. Но стоит внести в код ошибку против конкретного требования, и большая часть тестов её не заметит. Исследователи измеряли это через мутации: берут рабочую программу, специально ломают в ней одно требование и смотрят, упадёт ли хоть один тест. Лучший агент поймал только около 55% таких поломок, большинство остальных — меньше 40%.
Главная находка: агент понимает спецификацию, но плохо проектирует проверки. Он пишет тест на основной сценарий и пропускает комбинации входных данных и крайние случаи. Например, проверяет команду с одним файлом, хотя в требованиях сказано «принимает несколько файлов». Тестов при этом получается заметно меньше, чем у человека-эталона: у одной из моделей примерно в пять раз. Дело не в том, что требования непонятны. Когда агенту дали ещё и рабочую программу для сверки, сила тестов почти не изменилась.
Практический вывод: сообщение «все 120 тестов прошли» ничего не говорит о качестве проверки. Тесты нужно требовать по каждому требованию и по комбинациям входов, а их силу проверять поломкой кода. Ещё два рычага, подтверждённые в статье: подробная спецификация и более высокий уровень рассуждений модели.
Схема метода
Статья — бенчмарк, а не техника. Но её способ проверки силы тестов читатель может повторить вручную:
ШАГ 1: Дать агенту подробную спецификацию (по разделам-требованиям) → набор тестов
ШАГ 2: Прогнать тесты на рабочей версии → доля валидных (V)
ШАГ 3: Сломать код ровно в одном требовании (мутант) → один мутант на требование
ШАГ 4: Прогнать тесты на мутанте → упал хоть один? Да = мутант убит
ШАГ 5: Доля убитых мутантов (M) = реальная сила тестов
Шаги 3–4 можно поручить самому агенту отдельным запросом. Тогда это станет самопроверкой, которую в статье никто не измерял (см. «Адаптации»).
Пример применения
Задача: Вы руководитель небольшой команды, которая делает калькулятор стоимости доставки для интернет-магазина. Правила тарифа: вес, зона, наложенный платёж, бесплатная доставка от 5 000 ₽, пункты выдачи и курьер. Разработчик с Claude Code написал реализацию и тесты, «все зелёные». Вы хотите убедиться, что тесты поймают ошибку, например забытую скидку при комбинации «наложенный платёж + ПВЗ».
Готового промпта в статье нет. Ниже сборка по её выводам: тесты по каждому требованию, комбинации входов и проверка поломкой.
Промпт:
Ниже спецификация калькулятора доставки. Каждое требование пронумеровано.
[R1] Бесплатная доставка при сумме заказа от 5 000 ₽ — только для курьера.
[R2] Для ПВЗ скидка 10% от тарифа при сумме от 3 000 ₽.
[R3] Наложенный платёж добавляет 3% от суммы заказа, но не менее 50 ₽.
[R4] Вес свыше 20 кг — надбавка 15 ₽ за каждый следующий килограмм.
[R5] Зона 3 (Дальний Восток) — коэффициент 1,8 к базовому тарифу.
[R6] Если сочетаются скидка ПВЗ и наложенный платёж, сначала применяется скидка, потом комиссия.
Напиши тесты в tests/test_delivery.py.
Правила:
1. Для каждого требования — отдельные тесты. В начале каждого теста комментарий с номером требования.
2. Для каждого требования проверь границы: ровно на пороге, на 1 ₽/1 кг ниже и выше.
3. Отдельно напиши тесты на комбинации требований: каждая пара из R1–R6, где они могут пересекаться, и порядок применения из R6.
4. Если в требовании есть список («несколько», «любой из»), подай в тест минимум два-три элемента, а не один.
5. В конце выведи таблицу «требование → сколько тестов → какие комбинации покрыты». Если у требования меньше трёх тестов, объясни почему.
Не говори, что тесты хорошие. Покажи покрытие таблицей.
Результат: Агент вернёт файл с тестами, где у каждого стоит ссылка на требование. В конце будет таблица покрытия: по каждому из R1–R6 видно число тестов и комбинации. Тестов будет заметно больше, чем при обычной просьбе «напиши тесты». Следующим запросом можно попросить агента сломать по одному требованию и показать, какие тесты упали.
Почему это работает
Слабость LLM. Задача «напиши тесты» кажется агенту выполненной, когда есть набор осмысленных проходящих тестов. Он закрывает основной сценарий и считает дело сделанным. Слабые места лежат на стыках: два файла вместо одного, пороги, порядок применения правил. Проверять их он по умолчанию не стремится.
Сильная сторона. Агент хорошо читает спецификацию. Реализации по тем же спецификациям проходили до 93% эталонных тестов. Если явно указать, что и как покрывать, он может это перечислить и написать.
Как метод это использует. Он заменяет вопрос «хватит ли тестов?» вопросом «что поймает поломку этого требования?». Это превращает размытую цель в проверяемую: у каждого требования должны быть тесты на границы и комбинации.
Рычаги управления: - Детальность спецификации. Самый сильный рычаг в статье. С подробной спецификацией сила тестов у Sol — 25,5%, с обычной документацией репозитория — 4,0%. Чем размытее требования, тем слабее тесты. - Размер спецификации. Чем больше требований, тем хуже агент их покрывает. Режьте большую спецификацию на части и просите тесты по разделам. - Уровень рассуждений. У Sol от низкого к xhigh сила тестов выросла с 31,3% до 46,5%, цена — с $0,45 до $2,4 за задачу. Это отдача с убывающим эффектом, а не чудо. - Количество тестов. Модели с самыми слабыми результатами писали заметно меньше тестов. Требование «минимум N тестов на требование» работает в ту же сторону, но в статье его напрямую не проверяли.
Шаблон промпта
Вот спецификация. Каждое требование пронумеровано.
{спецификация_с_нумерацией_требований}
Напиши тесты в {файл_или_папка_для_тестов}.
Правила:
1. Для каждого требования — отдельные тесты. В начале каждого комментарий с номером требования.
2. Для каждого требования проверь границы: на пороге, чуть ниже, чуть выше.
3. Отдельно напиши тесты на комбинации требований, которые могут пересекаться: {список_пересечений_или_«найди сам»}.
4. Если требование говорит о нескольких значениях ({пример: «несколько файлов», «любой из статусов»}), подай в тест минимум два-три, а не одно.
5. В конце выведи таблицу «требование → число тестов → покрытые комбинации».
Если у требования меньше {минимум_тестов} тестов, объясни почему.
Не оценивай качество тестов словами. Покажи таблицей.
Подставьте в {спецификация_с_нумерацией_требований} ваши требования с номерами. Если их нет в документе, сначала попросите агента разбить текст на нумерованные требования.
🚀 Быстрый старт — вставь в чат:
Вот шаблон запроса на генерацию тестов. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, где лежат требования, какие из них могут пересекаться и какие там пороги и списки значений. Это нужно, чтобы правила про границы и комбинации заработали на ваших данных, а не остались общими словами.
Ограничения
⚠️ Нет проверенного промпта: Авторы не тестировали, улучшает ли просьба «покрой комбинации» силу тестов. Они измерили проблему и несколько факторов (спецификация, рассуждения, исполняемый эталон). Шаблон выше — наша сборка по их выводам, её нужно проверять на своих задачах.
⚠️ Узкий тип проектов: 165 консольных утилит на Rust, Go и C/C++ с тестами «вход → выход». Веб-интерфейсы, базы данных и интеграции с внешними сервисами не проверяли.
⚠️ Корреляция, не причинность: Модель, которая сама создавала мутанты и запускала программы, писала лучшие тесты. Но модель Sol без этого обошла DeepSeek. Совет «пусть агент сам ломает код» — гипотеза, а не доказанный приём.
⚠️ Дорого и долго: Лучший результат стоил около $10 и 37 минут на задачу. Рост цены даёт всё меньший прирост.
⚠️ Спецификация авторов — не ваша: Их спецификации выросли из эталонных тестов и прошли несколько циклов доработки. Обычное ТЗ почти всегда хуже, и результат будет ближе к 4%, чем к 25%.
⚠️ Правильные спецификации не спасают от слабых тестов: Даже с рабочей программой для сверки сила тестов почти не изменилась. Подробные требования необходимы, но недостаточны.
Как исследовали
Исследователи из ETH Zurich взяли 165 открытых программ с эталонным кодом и эталонными тестами. Из тестов агент собрал подробную спецификацию, в среднем около 5 000 слов. Затем для каждого требования создали мутанты: копии программы, сломанные ровно в одном месте. Мутанты дорабатывали, чтобы их убивал один тест, а не половина набора. Доля таких мутантов выросла с 32% до 73%.
Спецификации чистили циклами: агенты писали тесты и код по черновику, ошибки разбирали и классифицировали. Если вина лежала на спецификации, её исправляли, пока ошибки из-за неточностей не опустились ниже 5%. Затем шесть современных агентов получили только спецификацию без интернета и должны были написать полный набор тестов.
Сюрприз был в разрыве между показателями. Тесты валидны на 88–96% (кроме двух слабых моделей), реализации по тем же спецификациям проходят до 93% эталонных тестов, а мутанты ловятся лишь на 38–56%. Значит, спецификация понятна и агент её понимает, не хватает именно умения проектировать проверки. Это подтвердили два контрольных опыта. Рабочая программа для сверки подняла валидность тестов с 94,4% до 98,4%, а силу почти не сдвинула (37,7% → 38,1%). Замена спецификации на документацию из репозитория обрушила силу тестов с 25,5% до 4,0%: агент писал на 40% меньше тестов, и они чаще были неверными. Разбор ошибок показал типичный провал: основная функциональность проверена, а комбинации входов и крайние случаи пропущены.
Адаптации и экстраполяции
🔧 Техника: добавить самомутацию → увидеть дыры в тестах сразу
Статья показала, что лучшие модели сами создавали мутанты, но редко: Opus делал это лишь в 33 из 165 задач. Идея в том, чтобы вынести этот шаг в явную инструкцию. Это наша гипотеза, а не проверенный приём:
Теперь возьми по одному требованию из R1–R6. Для каждого сломай код ровно в одном месте,
не трогая остальное. Запусти тесты. Покажи таблицу: требование → что сломано → упал ли тест
(какой именно). Если мутант выжил, допиши тест, который его убьёт.
🔧 Техника: разбить спецификацию на части → меньше потерь покрытия
В статье сила тестов падала с ростом числа разделов. Вместо одного запроса на 40 требований дайте агенту по 8–10 требований за раз и проверяйте таблицу покрытия после каждого блока. Это тоже наша гипотеза по их корреляции.
Ресурсы
- TestSuiteBench: CodingAgentsStruggle to Generate Strong Test Suites from Specifications (Preprint)
- Авторы: Kazuki Egashira, Niels Mündler-Sasahara, Martin Vechev (ETH Zurich), Mark Niklas Müller (LogicStar.ai)
- Сайт: testsuitebench.com
- Код: github.com/eth-sri/testsuitebench; данные: huggingface.co/collections/eth-sri/testsuitebench
- Связанные работы: ProgramBench (Yang et al., 2026), SWT-Bench (Mündler et al., 2024), SWE-Mutation (Sun et al., 2026), NL2Repo-Bench (Ding et al., 2025)