Как стать автором
Обновить

Комментарии 4

всё никак не доберусь до того чтобы попробовать мутационное тестирование на пет проекте. К сожалению в работе проекты большие, тестов много, выполняются долго(минуты). Хотя можно подумать и о том чтобы ночами гонять тесты по одному и выстроить очередь тестов по времени последнего изменения. Заниматься надо, а пока других задач не в проворот
и отдельно вопрос, а как он понимает какой код вообще стоит мутировать, он анализирует код теста и ищет что из него вызывается?
Так это ж дело нехитрое, как говорится, «ломать — не строить»: мутаторы применяются бездумно, где только возможно. И соответственно, если есть какая-то новая часть кода, которая вообще не упоминается в тестах и даже не вызывается, то падают и покрытие, и MSI, причем последнее заметно сильнее, потому что к вообще не тестированной функции можно применить целое множество мутаторов и получить при этом пройденные тесты
Очень интересная штука. Решил попробовать на своих модулях.
В некоторых модулях у меня 100% coverage, в некоторых 90+% а дальше лень.

Результаты для меня.
Полезные
1. Индексы. Мутация arr[idx + 1] в arr[idx — 1] увидела, что нет теста с 2 элементов.
2. Неиспользуемые опции. opt = {use_a:true} заменило на opt = {use_a:false} и поведение не поменялось. Хотя use_a не выбросило бы как warning т.к. переменная использовалась, но не в тех случаях которые в тестах.

Бесполезные
1. coffee компилирует for hki in [0… max_hki] в что-то такого вида (пример выжившей мутации):
-           for (hki = _w = 0; 0 <= max_hki ? _w < max_hki : _w > max_hki; hki = 0 <= max_hki ? ++_w : --_w) {
+           for (hki = _w = 0; 0 <= max_hki ? _w < max_hki : _w >= max_hki; hki = 0 <= max_hki ? ++_w : --_w) {

Ну, можно поставить by 1, но идеологически ошибки нету, а в мутации есть и это не дает никакой пользы.
2. Я нигде не проверял текст exception'а. Потому все мутации в формировании имени exception'а выжили.
Ну серьезно. Мне не важно с какой ошибкой оно падает, главное, что падает. Т.е. ок, я поправлю тесты, внесу туда текст exception'а, но это не улучшит проект.

С чем я столкнулся при работе.
Проблема 1. Не поддерживается coffee.
Решение. Скоприровать и пройтись iced -c по всем файлам, а coffee удалить
Проблема 2. Оно очень плохо работает с асинхронными тестами с коробки
Решение. timeoutFactor: 3 иногда timeoutFactor: 10
Проблема 3. Некоторые мутации опасны для host машины.
Пример. Для тестов нужно записать в fs а мутация меняет папку.
Пример. Для тестов нужно очистить какую-то директорию через rm -rf.
Пример. Мутация вызывает бесконечный цикл меняя условие if (can_be true){break} на if (false){break} в while(true)
Решение отсекаем по timeout
Пример. Мутация вызывает бесконечное выделение памяти. После чего падает child у runner'а, после чего падает основной runner не выдавая отчёта.
Решение отсекаем по небольшому timeout дабы не успело выделить всю память.

Некоторые проблемы требуют взаимоисключающих решений. В одном случае увеличить timeoutFactor в другом наоборот оставить как есть, а иногда и уменьшить.
Проблема 4. Если тесты больше 30 сек.
Проблема 5. Если количество мутантов больше 1000.
Решение. Берём большой сервак на много ядер.
Но в пределе оно не умеет масштабироваться на несколько серверов.
С другой стороны запускать stryker на каждом чихе CI не самая лучшая идея. Это больше как еженедельная профилактика. Как статический анализатор.

Проблема 6. Была реальная ошибка, которая заключалась в том, что не передали последний параметр в функцию. Такого мутатора по умолчанию нет. Coverage не увидел.
Решение 1. Typescript. Но не поможет если параметр опциональный.
Решение 2. Написать мутатор самому. Еще не написал.

Проблема 7. Оно требует mocha^2.3.3, а уже есть 4-я.
Я забил.
Проблема 8. Кажется глобальный stryker и в node_modules ведут себя по-разному. Глобальный игнорирует опции в stryker.conf.js.
Но это неточно. И надо разбираться. Потому issue не постил.

Вердикт. Интересно, попробовал, все-равно интересно. Пока есть некоторая хрупкость. Выделю сбойные случаи — напишу им issue.
Мало мутаторов. Плохо работает в случае серъезных сбоев. Не запускать с проектами которые работают с fs на машинке с полезными данными или подключёнными сетевыми шарами!!!
Буду ли я использовать его для своих проектов? Пока нет. Только как профилактику раз в месяц.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории