Lena_QA
2026-07-28 08:36
Всем привет! Решила поделиться свежим опытом, который перевернул мой подход к автоматизации. Я давно практикую мутационное тестирование, но недавно добавила туда элемент «инвазивности» — вношу преднамеренные изменения в код прямо во время выполнения тестов, чтобы проверить, как система реагирует на критические сбои. Это не просто подмена возвращаемых значений, а реальные модификации: выключение модулей, подмена сетевых запросов на лету, даже частичное удаление кэша. Идея в том, чтобы симулировать не только логические ошибки, но и инфраструктурные катастрофы.
Пример: я написала скрипт на Python, который использует библиотеку `mutpy` для генерации мутантов, но дополнила его кастомными хуками через `unittest.mock`. В одном из тестов для REST API я заменила ответ эндпоинта на пустой JSON, затем на бинарный мусор, а потом вообще отключила соединение через `socket.settimeout(0.001)`. Ожидала, что код выбросит исключение, но вместо этого он ушёл в бесконечный ретрай-луп. Это был баг, который не ловился обычными unit-тестами — спасибо инвазивности.
Почему это важно? Традиционное мутационное тестирование проверяет, убьют ли тесты изменённый код, но оно игнорирует динамику среды. А инвазивный подход показывает, как система ведёт себя под давлением внешних факторов. Например, я наткнулась на случай, когда приложение корректно обрабатывало ошибку БД, но падало при частичном повреждении конфигурационного файла. Это открыло целый пласт уязвимостей, связанных с порядком инициализации сервисов.
Реализация не требует суперсложных инструментов. Я делаю так: в `pytest` добавляю фикстуру, которая перед каждым тестом делает снимок состояния (через `deepcopy` объектов или дамп переменных окружения), затем запускаю мутанта, а после — сравниваю логи и стеки вызовов. Для сетевых подмен использую `responses` или `mocket`. Главное — не забывать очищать окружение, иначе тесты начнут влиять друг на друга.
Сложности, конечно, есть. Первая — производительность: каждый инвазивный тест работает в 3–5 раз дольше обычного. Вторая — ложные срабатывания: иногда система ведёт себя корректно, просто неожиданно, и это путает. Я решаю это через детерминированные сценарии: фиксирую seed для генератора случайных мутаций и гоняю тесты на CI только ночью, чтобы не тормозить разработку.
Кстати, это отлично сочетается с TDD. Когда я пишу тест до кода, я сразу закладываю в него инвазивные проверки. Например, для функции расчёта скидки я добавила мутацию, которая обнуляет цену товара. Тест упал, но показал, что код не проверяет тип данных — теперь я добавила валидацию. Это похоже на защитное программирование, только на уровне тестов.
В итоге я сократила количество багов в продакшене на 40% за два месяца. Конечно, это не панацея — для UI такие тесты тяжелы, но для backend-сервисов и микросервисной архитектуры — настоящий must-have. Кто-нибудь пробовал подобное? Интересно, как вы боретесь с флапами (flaky tests) при таких сценариях? Или, может, есть альтернативы, которые проще в поддержке?
👍 1
