Мутационное тестирование — честная метрика качества тестов

Команда требует 100% покрытия строк и добивается его. Руководство успокоено. Затем кто-то запускает Stryker на том же модуле, и мутационный балл возвращается равным 67% — треть внедрённых багов выжила. Худший выживший: Stryker сменил граничную проверку с amount > limit на amount >= limit, прогнал весь набор, и каждый тест всё равно прошёл. Набор выполнял эту строку в каждом прогоне — покрытие 100% — но ни один тест ни разу не подал ровно то граничное значение, на котором > и >= различаются. Число покрытия измеряло, что строка выполнилась, но никогда — что тест заметит её поломку. Это не одно и то же, и зазор составил треть кода.

Покрытие измеряет выполнение, а не обнаружение

Покрытие строк отвечает на слабый вопрос: вызвал ли тест выполнение этой строки? Оно ничего не говорит о том, упадёт ли хоть один тест, будь строка неверной. Этот зазор не академический — это разница между набором, который вас защищает, и набором, который лишь навещает ваш код. Можно вызвать функцию в тесте, выполнить в ней каждую строку и не проверить ничего осмысленного о результате; покрытие засчитает это как покрытое, и реальный баг на этой строке уедет в продакшен зелёным. Высокое покрытие почти необходимо, но радикально недостаточно: это пол «тест коснулся этого», а не потолок «тест стережёт это».

Мутационное тестирование измеряет то, что покрытие не может. Инструмент берёт ваш проходящий набор, вносит маленькое изменение в продакшен-код — мутанта — и перезапускает тесты. Меняет > на >=, + на -, && на ||, return x на return null, удаляет инструкцию. Если теперь тест падает, мутант убит — ваш набор обнаружил внедрённый баг. Если все тесты всё равно проходят, мутант выжил — ваш набор не заметил бы ровно эту поломку. Мутационный балл — это убитые ÷ (всего валидных мутантов), и, в отличие от покрытия, это прямое измерение силы обнаружения. Stryker (JS/TS, C#, Scala) и PIT (JVM) — стандартные инструменты; документация Stryker точно определяет состояния убит/выжил/таймаут/без-покрытия.

Выжившие мутанты — это ваши недостающие проверки, названные поимённо

Важен не балл, а список выживших мутантов. Каждый выживший — точное, действенное утверждение: «я изменил вот это, а твоим тестам всё равно». Граничный выживший — > стал >=, и ничего не упало — прямо говорит вам, что не хватает теста на граничном значении, самого частого класса реальных багов. Выживший &&→|| говорит, что логическое условие недотестировано. Выжившее удаление инструкции говорит, что побочный эффект никогда не проверяется. Это и есть настоящий продукт мутационного тестирования: оно превращает «ваши тесты где-то слабы» в «добавь проверку здесь, на этой строке, для этого случая». Это честный ревьюер, который читает ваши проверки, а не отчёт о покрытии.

Окупается оно ровно там, где покрытие лжёт сильнее всего: критическая логика с границами, деньгами, правами, переходами состояний. Его запуск всплывает тесты, которые вы бы написали, додумайся вы до случая — это та же проблема слепых пятен, которую property-тестирование атакует со стороны входов. Эти два подхода дополняют друг друга: property-тесты генерируют входы, которые вы не перечислили; мутационное тестирование находит выходы, которые вы не проверили. Оба существуют потому, что покрытие строк измеряет не то.

Цена: время CPU и эквивалентные мутанты

Мутационное тестирование не бесплатно, и из-за цены команды его дозируют, а не гоняют на всём. Главная цена — время: инструмент перезапускает (подмножество) вашего набора по разу на мутанта, поэтому модуль с сотнями мутантов прогоняет ваши тесты сотни раз. Прогон мутаций по всей кодовой базе может занять часы, что неприемлемо на каждом коммите. Практический шаблон — дозировать: гонять на изменённых файлах в CI (Stryker и PIT оба поддерживают инкрементальные/diff-прогоны) или прогонять полный проход ночью на критических модулях, а не весь репозиторий на каждый push.

Вторая цена — проблема эквивалентного мутанта. Некоторые мутации дают код, поведенчески идентичный оригиналу — например, мутация i < n в i != n в цикле, который всегда инкрементирует на единицу, где оба завершаются одинаково. Ни один тест не может убить эквивалентного мутанта, потому что обнаруживать нечего, но он засчитывается против вашего балла и требует человеческого суждения, чтобы его отбросить. Обнаружение эквивалентных мутантов в общем случае неразрешимо, поэтому вы разбираете их вручную. Это и есть честная сеньорская оговорка: мутационный балл ниже 100% ожидаем, выживших надо читать, а не слепо гнаться за ними, и цель — убить значимых выживших на критическом коде, а не идеальное число на всём.