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

Инструмент отмечает исполненные строки и сравнивает их с исполнимыми строками, включёнными в расчёт. Так работает coverage.py.

В отчёте есть проценты для строк, ветвей и функций. Посещение функции ещё не означает проверку всех её исходов. Atlassian разбирает эту разницу.

Руководителю нужен отчёт с областью расчёта: исключённые файлы, набор тестов и версия кода. Общий процент скрывает эти детали.

Учебный пример: при заказе от 10 000 ₽ полагается скидка 1 000 ₽. В коде её дают только выше порога. Тесты проверяют суммы ниже и выше него.

Покрытие помогает найти непройденный код. Ошибку в смысле «от этой суммы» оно не определяет: тесты уже посетили оба исхода.

Если агенту поручили описать поведение готового кода, он может записать текущий ответ как правильный. Скидка на пороге окажется нулевой и в коде, и в тесте.

Сначала нужен согласованный критерий готовности задачи. Сумма ровно 10 000 ₽ даёт 1 000 ₽ скидки. Этот ответ берут из условия покупки.

Агент получает входы и ответы до правки. Проверяющий сверяет с ними тест. GitHub советует просматривать тесты: зелёный прогон ещё не доказательство.

Для разбора технического долга тест фиксирует старое поведение перед переносом. Он сохраняет совместимость. Правильность для бизнеса проверяют отдельно.

В копии кода на время убирают нужное действие или меняют условие. Проверка, которая защищает это действие, должна упасть.

После исправления замените «от порога» на «выше порога». Тест на 10 000 ₽ должен заметить потерю скидки. Тесты ниже и выше порога её пропустят.

Автоматический перебор таких изменений называют мутационным тестированием. Stryker показывает ту же механику с заменой включительной границы на строгую.

Перебор изменений тоже не доказывает правильность всей задачи. Stryker описывает изменения без отличия результата. Выжившие изменения разбирают по смыслу.

Проверяющему может помочь другая модель. Ответ всё равно сверяют с задачей. Правила работы агента должны запрещать менять согласованный ответ ради зелёного прогона.

Тест исполняется в определённой среде и проверяет выбранные свойства. Пропущенное свойство остаётся без защиты.

Формальная верификация доказывает свойство только в пределах заданной модели программы.

Инженер ведёт машину агентов на vibecoding.ru. На открытой странице машины 8 октября 2026 указано 2 685 тестов на каждом пуше плюс ревью.

Опубликованного процента покрытия и клиентского кейса по теме у нас нет. Здесь разбираем две поломки сайта и границы зелёного прогона.

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

Поэтому в приёмке нужен результат на стенде. Действия после поломки разобраны в статье про ответственность за ошибки ИИ; здесь проверяем сценарий до выпуска.

Для одной задачи запросите пакет, который связывает правило бизнеса, тест и результат прогона. У каждой части должна быть та же версия кода.

Пакет начинается с ответа на пороге скидки. Подрядчик показывает падение при намеренной ошибке и успех после её удаления. Снимка зелёных галочек мало.

Если такой пакет некому вести, обсудите приёмку разработки. До старта договоритесь, кто сверяет сценарии и кто принимает результат.

В подписке на агентную разработку тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Запрашивайте проверенные сценарии вместе с кодом и тестами.

1. Покрытие отмечает исполнение. Запрашивайте область расчёта и исключения.

2. Ожидаемый ответ берут из задачи. Сверяйте его до приёмки теста.

3. Проверяйте тест выбранной ошибкой. Он должен заметить нарушение сценария.

4. Смотрите состав прогона. Выборочный набор не заменяет обязательные проверки.

5. Принимайте путь пользователя. Храните сценарии вместе с кодом и тестами.