Полезно ли мутационное тестирование на практике?

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

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

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

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

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

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

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

1. Создавайте мутантов.
2. Убедитесь, что мутации обнаружены тестами.

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

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

http://pitest.org/

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

http://www.eclemma.org/

Для освещения.

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

Мутационное тестирование - это угол атаки, который сильно отличается от методологий модульного / функционального / интеграционного тестирования.

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

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

Дядя Боб изменяет сообщение в блоге о тестировании

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

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

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

Developers have decided to redesign large chunks of code to make them testable just so a mutant could be killed, they have found bugs in complex logical expressions looking at mutants, they have decided to remove code with an equivalent mutant because they deemed it a premature optimization, they’ve claimed the mutant saved them hours of debugging and even production outages because no test cases were covering the logic under mutation properly. Mutation testing has been called one of the best improvements in the code review verification in years. While this feedback is hardly quantifiable, combined with the sheer number of thousands of developers willing to inspect surfaced mutants on their code changes makes a statement.

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

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

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

Тестовый пример для первого ведет себя по-другому из-за вышеупомянутой мутации, теперь возникло исключение. Таким образом, он не возвращает ожидаемый массив {6,3}. Однако наш второй тестовый пример остается таким же, потому что он также включает положительное число. Таким образом, это также дает исключение для положительных чисел. Теперь, если нам нужно написать успешный тестовый пример, который будет Ввод = {- 6, -6, -7, -3, -4} Ожидается = {-6, -3}