Является ли тестирование на мутацию полезным на практике?

Ответ 1

Полезность модульных тестов больше не обсуждается. Они важны в концепции качественного применения. Но как мы можем оценить их значимость? Индикатор покрытия кода до 100% не означает, что код проверен на 100%. Это всего лишь просмотр исполняемого кода во время выполнения единичных тестов. Тестирование на мутацию позволит вам больше доверять вашим тестам.

Это двухэтапный процесс:

• Генерировать мутанты.
• Убедитесь, что мутации найдены в тестах.

Я написал целую статью об этом процессе, включая некоторые конкретные случаи.

Ответ 2

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

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

Ответ 3

Я играл с питером для небольшого надуманного приложения:

http://pitest.org/

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

http://www.eclemma.org/

Для покрытия.

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

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

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

Ответ 4

Я знаю, что это старый вопрос, но недавно дядя Боб написал сообщение в блоге, очень интересное о мутировании тестирования, которое может помочь понять полезность этого типа тестирования:

Дядя Боб, мутирующий тестовое сообщение в блоге

Ответ 5

Недавно я провел несколько исследований по тестированию мутаций. Результаты здесь:

http://abeletsky.blogspot.com/2010/07/using-of-mutation-testing-in-real.html

Короче: тестирование на мутацию может дать некоторую информацию о качестве исходного кода и тестов, но это не то, что нужно использовать.

Ответ 6

Недавно я начал практиковать тестирование мутаций на С++, и это намного лучше, чем покрытие кода. В крайнем случае можно получить 100% охвата кода и 0% обнаруженных потенциальных ошибок (в моем случае он выявил ~ 80% поддельных ошибок) - конечно, это зависит от того, насколько хорошо вы генерируете ошибки.

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

В вашем отчете также должно быть указано изменение /diff, которое не было обнаружено в тестах. Затем вы можете исправить тесты.

Ответ 7

Мутационное тестирование помогло мне выявить проблемы с утверждениями тестового примера.

Например, когда вы получаете отчет, в котором говорится, что "ни один мутант не был убит тестовым примером x", вы смотрите, и оказывается, что утверждение было закомментировано.

Согласно этой статье, разработчики в Google используют тестирование Mutation в качестве дополнения к проверке кода и проверке запросов на извлечение. Они кажутся довольными результатами:

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

Ответ 8

Охват против мутационного тестирования. Старый вопрос, но недавно я наткнулся на недавний блог на эту тему. Довольно самоуверенный. Но различия между охватом и мутационным тестированием четко сформулированы.

https://pedrorijo.com/blog/intro-mutation/

Мой собственный опыт показывает, что Pitest довольно полезен, но поскольку среда выполнения взрывается, он работает только на одном очень быстром наборе тестов. На практике это ограничивает область применения мутаций.