Зелёные тесты ≠ хорошие тесты
Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.
Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не "поймает ли тест баг в этой строке", не "проверяет ли он правильность результата" - просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.
Мутационное тестирование - это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на -, True на False. Каждая такая поломка - мутант. Если после мутации все тесты по-прежнему зелёные - значит они ничего не проверяют. Покрытие есть, защиты нет.
Почему это важно именно сейчас?
Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что-то - и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай - тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.
Мутационное тестирование - единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% - плохо. 90%+ - тесты реально что-то защищают.
Кое-какие инструменты для такого тестирования уже есть: mutmut и cosmic-ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест-рана. Но запускать его не нужно на каждый коммит - достаточно на PR в критические модули.
Но есть нюансы. А где их нет, правда?
Первый: мутации рандомные. Замена > на >= - это не баг, который кто-то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой - формально проверка, по факту мимо.
Второй - ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% - и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод - 40 тестов красные. Поменял порядок полей в ответе - ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.
Это реально ловушка. Слишком гонишься за mutation score - получаешь хрупкие тесты. Не гонишься - получаешь видимость тестирования.
Перемены - впереди!
И вот тут становится по-настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case - ровно так, как ошибается человек. Или другая нейронка.
Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не "выжили ли тесты после рандомной поломки", а "выжили ли тесты после правдоподобной ошибки".
Парадокс в том, что мутационное тестирование было нишевым инструментом, пока тесты писали люди. Когда тесты пишет нейронка - идея становится обязательной. Правда инструменты пока не успели дозреть.
Ждём, когда мутанты станут умнее.
