Мутационное тестирование

Что такое мутационное тестирование? Если вкратце, то это когда мы меняем в коде "равно" на "не равно" и смотрим, какие тесты отвалятся. То есть проверяют ли они то, что и должны.

Я, кстати, это определение услышала на #yatest (Конференция Яндекса Тестовая Среда). Хотя что-то знакомое, я его явно слышала и раньше, просто успела забыть, что же это такое.

Так вот, на конференции ребята справедливо заметили, что если его просто взять и применить, то будет ой-ей. Представляете, код гигантского модуля реверснуть?

Но, с другой стороны, сразу вспомнила историю из жизни, и вот что я хочу сказать — да, на большом проекте или большом модуле такое тестирование не применимо в полном объеме. Но взять кусочек и посмотреть на него с зеркальной стороны бывает ну о-о-о-очень полезно.

Есть у нас в системе некие правила, которые говорят "если А сработало, ничего не делай", то есть оставь систему в исходном состоянии. Ну. как если на кнопку "Отмена" нажать (турецкий маркет — это простой маркет! Только на турецком... (с) Тестовая среда).

Есть автотесты, которые написаны по этому правилу и честно проверяют, что состояние системы не изменилось. В начальном состоянии базы мы указываем поле n_1, зная по конфигу, что n_1 — это артикул товара, например.

Уже тогда смущало то, что ничего не показывает, отработал тест как должен или он в принципе не сработал, вот состояние и не изменилось. Но ведь автотесты проверяет коллега, проводя ревью, это просматривается вручную, а раз все работает—- то и ок. А делать проверку на то, что что-то случилось, "дорого" (по ресурсам), не стоит оно того. Ну ладно.

Понадобилось мне тут похожую проверку сделать. С нуля писать не хочется, захожу я в модуль, где она точно есть, копирую себе. Потом, чтобы докрутить настройки, лезу в конфиг модуля, откуда копировала и смотрю, а что там значит n_1? А там этого поля... Нет!

То есть сначала тесты были правильные, но в какой-то момент времени конфиг поменялся, а тесты - нет. Но они продолжали работать, показывая "зеленый" результат. Почему? Потому что уже ничего не проверяли. Не нашел поле? И ладно, значит, ничего не буду делать, состояние базы не меняется, а тест того и ждет.

Вот тут-то мы и задумались о мутационном тестировании. Поправить автотест и проверить близлежащие? Ага, а вдруг такие еще где-то есть? Надо ведь не последствия исправлять, а думать, как искоренить причину, чтобы такого не было. Да и как найти все последствия, вручную проверять?

Вот и сделали проверку: если параметра нет в конфиге, значит, автотест подозрительный, вряд ли он что-то проверяет. Столько тестов попадало сразу! Вот так результат. В процентном соотношении, конечно, не много, но нашлись такие и в других модулях.

Это заставило задуматься о том. что:

1. Настройка слишком сложная, раз в ней так легко ошибиться, надо упрощать.
2. Мутационное тестирование — это мега-полезно! Главное, применять по чуть-чуть, чтобы сразу увидеть результаты.

Нет, конечно, до конференции яндекса я не знала (или не помнила?) этого умного названия "мутационное тестирование". Но вот что-то гложет, гложет. И теперь я понимаю, что.

Ребята! Посмотрите внимательно на свои тесты! Если система большая, их уже накопилось довольно много. И, возможно, часть из них устарела, а вы даже и не в курсе. Посидите, подумайте, можно ли где-то включить инверсию и посмотреть, что получится. Упадут ли те тесты, которые вы ожидаете? Результаты могут вас удивить! Тесты могут остаться "зелеными". А вот это уже сигнал — что-то тут не так.

И я считаю, что "мутационное тестирование" — это как свежий взгляд на систему. Как знаете, нанимаешь нового сотрудника и смотришь, как он реагирует на продукт, что удобно, а что нет. Ведь ты уже привык, что это работает именно так и можешь даже не замечать, насколько это сложно и неудобно. Также и с тестами. Сам же писал! Значит, хорошие  Но иногда и для них нужен свежий взгляд, очень помогает...