Тестирование мутаций в cpp без изменения / перекомпиляции кода
В настоящее время у меня есть некоторые тесты, которые обвиняют в том, что они не очень хорошо ловят ошибки. Я хочу провести мутационное тестирование, чтобы обнаружить их (и не допустить добавления новых бесполезных), но без неэффективного по времени цикла: измените код -> перекомпилировать -> запустить тесты -> изменить код -> перекомпилировать -> запустить тесты … и т. д.
Изначально я хотел как-то напрямую изменить двоичные эльфийские файлы (без перекомпиляции), но, как показали последующие посты, это не имеет смысла.
Решение
Хорошо, я смог решить это частично, разделив тестирование на мутации на 4 основных этапа:
- обрабатывать код во всех мутациях с помощью python / clang-tooling (выбранные выражения C ++ заключаются в специальный макрос, который делегирует вызовы класса мутации, который генерирует ID для каждой мутации, контролирует активацию операторов мутации и т. д.)
- перекомпилировать код (только однажды)
- параллельно запускать тесты с неактивными всеми мутациями и получать идентификаторы всех мутаций (если есть неудачные тесты, поместите их в список игнорирования),
- параллельно выполнять тесты при переключении мутаций во время выполнения (по идентификатору, полученному на предыдущем шаге) и собирать статистику (коэффициент уничтожения мутантов и т. д.)
Реализация осуществляется на python и C ++, она составляет около 1700 строк кода (с тестами) + незначительные адаптации в рабочем коде (CMake и файл gtest main.cpp). Он поддерживает только пару простых мутаций, но все равно делает удовольствие 🙂
Другие решения
Предполагая, что тесты выполняются быстро, а количество запусков достаточно велико (~ 1M, ~ 1k ??), я должен получить приблизительную оценку частоты попаданий потенциальных ошибок ??
Нет. Ваша «однобитовая ошибка где-то в двоичном файле elf» может повредить что угодно (от формата elf до сегментов данных, стеков вызовов и т. Д.). Таким образом, вы не получите никаких приблизительных оценок количества ошибок, но получите приблизительную оценку вероятности выполнения испорченного исполняемого файла (который вообще ничего не говорит о вашем приложении).
В настоящее время у меня много тестов, которые обвиняют в том, что они вообще не обнаруживают ошибок.
Это то, к чему вам придется обратиться напрямую, и для этого нет кратчайших путей: вам нужно будет установить новые цели для ваших тестов, реорганизовать код для их поддержки и реализовать их.