I’ve been a big fan of Mutation Testing since I discovered PIT. As I dive deeper into Rust, I wanted to check the state of mutation testing in Rust. Starting with cargo-mutants I found two crates for mutation testing in Rust: cargo-mutantsand mutagen mutagen hasn’t been maintained for three years, while cargo-mutants is still under active development.

As an ardent promoter of Mutation Testing, I sometimes get comments that it’s too slow to be of real use. This is always very funny as it also applies to Integration Testing, or GUI. Yet, this argument is only used againt Mutation Testing, though it cost nothing to setup, as opposed to the former. This will be the subject of another post. In this one, I will provide proposals on how to speed up mutation testing, or more precisely PIT, the Java Mutation Testing reference.

Since about a year and a half, I do a lot of presentations on Mutation Testing. In those, my point is to show that Code Coverage’s only benefit is that it’s easy to compute but that it’s meaningless - hence Mutation Testing. Since some time, I’ve been interested in Kotlin, a language from JetBrains that runs on the JVM. It’s only natural that I wanted to check how Mutation Testing could be applied to the Kotlin language.

Last week, I took some days off to attend Devoxx France 2014 3rd edition. As for oysters, the largest talks do not necessarily contain the prettiest pearls. During this year’s edition, my revelation came from a 15 minutes talk by my friend Alexandre Victoor, who introduced me to the wonders of Mutation Testing. Since I’m currently writing about Integration Testing, I’m very much interested in Testing flavors I don’t know about.