Continuing the discussion from What dev-related stuff have you been up to?:

“Perfect” would take further definition, but to “check” or “improve”, yes, that’s one of the main benefits. The other main one is to find “dead” code, that’s unreachable or redundant or otherwise not doing anything important enough that you’ve made a test depend on it.

Not quite, but thinking in “size” terms like that is one of the metaphors used by Markus Schirp, the author of Mutant. He likens it to trying to ensure that the area covered by the unit tests is the same as the area covered by your code. Where the tests cover but the code doesn’t, you have a failing test, which of course shouldn’t be happening, and is discovered by the usual means of just running the tests. The more interesting case is where the code covers but the tests don’t, which means you have untested code, that should be either tested or removed. So, the effect on your test suite is generally not to shrink it but to expand it.

Note though that code being “tested” doesn’t mean it needs its own explicit tests, just that it needs to make a difference to the success or failure of at least one test. So frex you don’t need to have tests explicitly for every little trivial function like a getter or setter – but if you mutate a getter or setter, it darn well better break some test, generally one on more complex code that depends on that getter or setter.

Yes, there are some similarities. I’ve made a similar comparison in some of my talks on it, specifically referring to “fuzzing”, a form of property testing designed to find security holes. You can think of mutation testing like fuzzing the code rather than the data. However, another big difference is that mutation testing (generally) isn’t random. A mutation testing tool will generally apply all the mutations it knows how to do. (Except that some of the smarter ones will look at results of certain ones and know it doesn’t need to apply certain other ones, as it will be able to predict the results.)

It might help to watch one or two of my talks on it. The playlist is at https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS and they’re in reverse chronological order. Other than the earliest one, which I recommend you ignore, they range from a 22 minute overview, to a 52 minute deeper dive.