Мутационное тестирование хорошо забытое, но актуальное с AI
Методу почти 50 лет, и почти никто им не пользуется. Не потому, что он не работает: Just нашли значимую связь между способностью набора убивать testing mutations и ловить реальные дефекты, независимо от покрытия. В текущих реалиях это актуально, потому как тут AI реально помогает снизить TCO в области QA.
Где заложена цена Инструмент вносит в код маленькое изменение, например, меняет >= на >, инвертирует условие или удаляет вызов. Получается fork с мутацией. Далее идут тесты: упал хотя бы один - отлично. А вот если тесты зелёные и мутантация выжила, то у вас проблемы - можете поменять это место, а никто не заметит. На самом деле, машинная часть давно решена. Например, Google мутирует только изменённые и покрытые строки, по одной мутации на строку, и это работает на двух миллиардах строк кода. Но платите вы за другое: у них разработчики сочли непродуктивными 85% показанных мутантов, а разбор одного занимает минуты, тем более с AI. Похожее получили в Facebook.
Почему разбор такой дорогой Выживший мутант ставит вопрос: это поведение кто-то обязан был зафиксировать? А сам по себе ответ лежит не в коде. Он лежит в спецификации разработки. Поведение либо требовалось, и тест обязан его держать, либо никого не интересует, и такую мутацию надо подавлять. В статье про долг понимания я писал, что при AI генерации понимание перестало возникать побочным продуктом написания самого кода и чтения спецификаций. Здесь та же развилка с другой стороны: у человека, разбирающего мутантацию, не всегда под рукой спека, а если и да, то намерение use cases может быть не явным. Он восстанавливает его по коду и тестам, то есть занимается реверс-инжинирингом.
Что меняет spec-driven разработка Если артефакты разработки выверены с критериями приёмки, тогда разбор перестаёт быть человеческой работой. Агент получает выжившию мутантацию и релевантный фрагмент спеки, после чего раскладывает на три корзины: 1. Спека требует поведение, теста нет: нашли проблему и пробел и пишем тест. 2. В спеке ничего нет и поведение из требований не следует - ок, тогда подавляем эту мутацию. 3. Поведение выглядит существенным - эскалация человеку, потому что пробел в спеке дороже, чем в тестах. Это ровно классификация дрейфа, о которой я писал раньше, только вход не диф, а в мутантации. И здесь важно, откуда мутация берётся. Инструмент строит ее по синтаксису, и он не знает ваших представлений о том что критично в логике и не повторит вашу ошибку. А вот для кода, где реализацию и тесты писал один агент из контекста, это единственная дешёвая проверка. И чаще всего в таком случае будет зелёный прогон, что подтверждает согласованность двух артефактов, и только.
Гибридный режим Полной спеки у большинства нет, часть кода пишут руками. Тогда входом для разбора работает то, что есть: контракты в OpenAPI, ADR, критерии приёмки в тикете, человеческий текст в PR. Да, точность ниже, а эскалаций больше, но уже в этом случае минуты на разбор мутаций превращаются в секунды на большинстве случаев при осознанном AI применении. Есть и побочный приятный эффект - мутации показывают, где документации нет вообще! Именно там, где агент не может решить, требовалось поведение или нет, у вас нет ни спеки, ни ADR, ни объяснения.
Что не меняется Мутация не проверяет правильность поведения. Тест, утверждающий не то, убивает мутации не хуже правильного теста Часть мутаций эквивалентна оригиналу, убить их нельзя, и задача в общем случае неразрешима. При этом стопроцентный score недостижим. Поэтому не стоит из score делать KPI. В Google мутации остаются находкой в ревью и в отчёт не попадают. Но как только score становится целью, его начинают набивать, и вы получите тот же спектакль, что с покрытием, только дороже.
С чего начать уже сейчас Возьмите модули, где ошибка стоит реальных денег. Мутируйте дифф, а не базу. А разбор отдайте агенту, при этом спорное эскалируйте инженеру. Дале посчитайте, сколько мутаций он подавил со ссылкой на спеку, а сколько вслепую. И вот как раз ваш второй показатель и есть ваш долг понимания в штуках.
