Создание юнит-тестов быстро проваливается для мутационного тестирования - PullRequest
6 голосов
/ 16 апреля 2009

Одна проблема, связанная с тестированием мутаций , заключается в том, что он медленный, потому что по умолчанию вы выполняете полный тестовый запуск (либо тестовый файл, либо набор тестовых файлов) для каждой сгенерированной мутации.

Один из способов ускорить тестирование на мутации - остановить тестовый запуск для данного мутанта, как только обнаружится один сбой (но только во время тестирования на мутацию). Еще лучше было бы, чтобы тестер мутаций запомнил, какой был первый тест, убивший последнего мутанта, и передал его сначала следующему мутанту. Есть ли в ruby ​​что-нибудь из перечисленного, или моя лучшая ставка - начать исправление обезьян?

(Да, я знаю, что юнит-тесты должны быть быстрыми. И показ всех неудачных тестов полезен вне мутационного тестирования, так как помогает вам не просто определить, что что-то не так, но и точно определить, где происходит ошибка)

Редактировать : Я сейчас использую хекл с тестом / модулем. Если тест / модуль не может вспомнить, какие тесты не выполняются между выполнениями, возможно, Хекл или что-то другое, хекл, может запомнить это.

Ответы [ 3 ]

2 голосов
/ 10 декабря 2012
Инструмент

My mutant использует параметр rspec2 --fail-fast для немедленной остановки при обнаружении сбойного примера. Вместе со стратегией --rspec-dm2, которая выполняет только затронутые модульные тесты, мы получаем очень быстрое тестирование покрытия мутаций. См. asciicast для демонстрации (скорости).

2 голосов
/ 16 апреля 2009

Самое лучшее, что вам нужно - это проверить источник heckle из github, исправить его и отправить этот патч разработчикам. Вы должны быть в состоянии написать собственный бегун теста для heckle.

Исправление обезьян никогда не является ответом на что-то подобное. На самом деле, исправление обезьян почти никогда не отвечает ни за что.

1 голос
/ 29 апреля 2010

Одним из подходов, которые я начал использовать, было написание модульных тестов для каждого метода и помещение их в отдельные файлы, организованные как rubyspecs. Я запускаю каждую спецификацию по отдельности, указывая точный метод, который хочу использовать. У меня есть грабли, которая управляет всем этим и в конце печатает отчет с ошибками, если таковые имеются.

В конце я получаю полный охват каждого метода, не дожидаясь результатов. Кроме того, это даже лучше, чем обычный подход, который используют все, потому что я не получаю никакого случайного покрытия - спецификации каждого метода должны охватывать все мутации этого метода.

...