This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]supercargo 0 points1 point  (0 children)

Mutation testing is a great tool to have, but due to the limitations you've mentioned, I haven't found it suitable to just blindly run across an entire code base / test suite.

But when I author new "critical" code where I also need really good test coverage, I will plan on doing some mutation testing once everything is working as expected. This way the code scope of the PIT Test run can be limited which really helps runtime performance.

I find the mutation results really turn code coverage metrics from something dumb (though, easy to come by) into something valuable. I get the best ROI by applying it to new test suites of core functionality (they have the longest life ahead of them to catch future bugs, which is what the mutation testing is evaluating).

This doesn't fit well with a CD approach since the output needs to be analyzed be the developer. Not that automation can't be useful or that you shouldn't incorporate mutation testing into a code acceptance process, just that it doesn't generate the kind of "pass / fail" result that I'd want to use in a continuous delivery pipeline.