Создание юнит-тестов быстро проваливается для мутационного тестирования
Одна проблема, возникающая при тестировании мутаций, заключается в том, что он медленный, потому что по умолчанию вы выполняете полный тестовый запуск (либо тестовый файл, либо набор тестовых файлов) для каждой сгенерированной мутации.
Один из способов ускорить тестирование на мутации - остановить тестовый запуск для данного мутанта, как только обнаружится один сбой (но только во время тестирования на мутацию). Еще лучше было бы, чтобы тестер мутаций запомнил, какой был первый тест, убивший последнего мутанта, и передал его сначала следующему мутанту. Есть ли в ruby что-нибудь из перечисленного, или мой лучший выбор - начать исправление обезьян?
(Да, я знаю, что юнит-тесты должны быть быстрыми. И показ всех неудачных тестов полезен вне мутационного тестирования, так как помогает вам не просто определить, что что-то не так, но и точно определить, где происходит сбой)
Изменить: в настоящее время я использую хекл с тестом / модулем. Если тест / модуль не может вспомнить, какие тесты не выполняются между выполнениями, возможно, Хекл или что-то другое, хекл может это запомнить.
3 ответа
Самое лучшее, что вы можете сделать, это проверить исходный код на github, исправить его и отправить этот патч разработчикам. Вы должны быть в состоянии написать пользовательский тестовый бегун для heckle.
Исправление обезьяны никогда не является ответом на что-то подобное. Фактически, исправление обезьян почти никогда не является ответом ни на что.
Мой инструмент- мутант использует rspec2 --fail-fast возможность немедленно прекратить работу при обнаружении неудачного примера. Вместе с --rspec-dm2 Стратегия, которая выполняет только затронутые модульные тесты, позволяет нам очень быстро тестировать покрытие мутаций. См. Этот asciicast для (скорости) демонстрации.
Одним из подходов, который я начал использовать, было написание модульных тестов для каждого метода и помещение их в отдельные файлы, организованные как rubyspecs. Я запускаю каждую спецификацию по отдельности, указывая точный метод, который хочу использовать. У меня есть грабли, которая управляет всем этим и в конце печатает отчет с ошибками, если таковые имеются.
В конце я получаю полный охват каждого метода, не дожидаясь результатов. Кроме того, это даже лучше, чем обычный подход, который используют все, потому что я не получаю никакого случайного покрытия - спецификации каждого метода должны охватывать все мутации этого метода.