Мутационное тестирование показывает, замечают ли тесты агента намеренно внесённую ошибку

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

Повторяемость ответа модели ещё не гарантирует одинаковую правку агента при новом запуске.

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

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

Как выглядит проверка на бизнес-правиле? Возьмём учебный пример: скидка положена при заказе от 10 000 ₽ включительно. В коде это сравнение суммы с порогом через «больше или равно».

Мутатор заменяет его на «больше». Заказ ровно на 10 000 ₽ теперь остаётся без скидки. Такая маленькая правка называется мутацией, а изменённая версия кода называется мутантом.

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

На время прогона тесты фиксируют. Мутации применяют по одной в копии кода, которую не выпускают пользователям. Подгонка тестов под ошибку испортит измерение.

Ожидаемый результат нужно записать до прогона. Если скидка по ошибке задана «строго выше порога» и код с тестом согласны, мутатор не восстановит настоящее требование бизнеса.

Зелёные тесты не отличили изменённый код от исходного. Найдите причину в отчёте: просьба агенту «проверить внимательнее» её не объяснит.

У скидки не проверена граница. Другие причины: тесты не запускают код или мутация не меняет результат на допустимых входных данных.

Эквивалентная мутация сохраняет результат. Прибавление нуля и умножение на единицу дают ту же сумму: тест на их различие не защитит скидку.

Эквивалентность нужно объяснить. Исключив неудобную мутацию ради процента, можно скрыть пропущенную границу скидки.

Общий mutation score Stryker учитывает мутации с упавшим тестом или таймаутом. В знаменателе все пригодные мутации, включая код без покрытия.

Возьмём учебный отчёт с 10 мутациями. Из них 6 заметили тесты, 1 закончилась таймаутом, 2 выжили и 1 не имела покрытия.

Ни 70 %, ни 100 % не обещают такую долю найденных дефектов. Прогон ограничен выбранными изменениями, пропущенное требование может в них не попасть.

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

24 сентября 2026 тесты пропустили несовместимый ответ функции: тестовая среда обходила валидатор ответа. Сначала нужна проверка этого слоя.

Человек, который принимает результат, несёт ответственность за выпуск. После поломки он принимает тест, который падает на дефекте и проходит после исправления.

В правилах для агентов проверка не даёт вернуть уже известное нарушение. Мутационное тестирование добавляет другой вопрос: какой ещё маленький дефект эта проверка пропустит?

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

Задача исполнителю должна включать ограниченную область и условия приёмки. Это та же постановка задачи агенту, только результатом служит доказательство силы тестов.

Инженер сначала проверяет, что исходные тесты проходят устойчиво. Если они падают сами по себе, красный результат после мутации ещё не объясняет, что именно обнаружено.

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

Область проверки и исключения должны остаться видимыми. Скриншот с процентом не покажет, что расчёт скидки исчез из задания мутатору.

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

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

Если некому вести эту работу, проверку критичной функции можно поставить отдельной задачей в очередь агентной разработки. «Один проект» стоит 250 000 ₽ в месяц, один поток работы.

Цена проверена на /services 8 октября 2026. Это подписка на работу над проектом, а не цена разового мутационного аудита.

1. Зелёный прогон сообщает, что тесты прошли. Проверьте, падают ли они при нарушении критичного правила.

2. Начните с одной функции и требования, записанного отдельно от кода.

3. На время измерения зафиксируйте тесты и вносите мутации по одной.

4. Разбирайте выжившие изменения, таймауты и исключения отдельно от процента.

5. После нового теста повторите ту же мутацию и сохраните результат.