OK, so... you write tests to verify that your code is doing what it is expected to do. But who verifies that the tests are "good"? We all know that test coverage means "almost" nothing, so... Who watches the watchmen?
This will be an introduction talk and demo to mutation testing 🙂
Mutation testing 101
Form3 Friday Sharing
25th June 2019
“Internal” vs “External” quality
The system / component / whatever behaves as expected...
Speciﬁcation by example / ATDD / BDD
Metrics, metrics everywhere...
Test coverage: are we covering all the “possible” behaviours of the system?
“Tell me how you measure me,
and I will tell you how I will behave”
Eliyahu M. Goldratt
“You get what you measure”
Mutation testing to the rescue!!
Simple examples of mutators
Void method calls
Conditional boundaries mutators
Negate conditional mutators
Return values mutator
Void method call mutator
Demo time (in Java… oopsss!!)
https://github.com/sandromancuso/Gilded-Rose-Kata (100% test coverage)
High test coverage means almost NOTHING. Low test coverage is a smell...
Mutation testing: only for isolated tests (aka “unit tests”): tests which are fast
Start with the basic mutators
Depending on the complexity and size of the code, it can be very time/resource
consuming, watch out!! (combinatorial explosion)
In Pitest you can activate “incremental analysis” (experimental feature)
GOTO 2015: Mutation testing in Python
Mutation testing in Python with Cosmic Ray
Vicenç García en SCBCN (in Spanish)
Madrid JUG (in Spanish)