Bob was a lackadaisical teenager, who used to live in the harmless land of Excercism.io
But then the MUTANTS came ... and everything we knew, had changed ...
This example proofs that 100% code coverage can be very misleading. Run all the specs with rake
:
Cool, everything is working and the generated report confirms a coverage of 100.0%.
You can take a detailed look with open coverage/index.html
.
If you look at the specs, only the Bob class has some reasonable tests to ensure the functionality of Bob. But Bob uses the Statement class which holds most of the "business logic" (what is covered through the specs from Bob).
Now run the mutation tester with rake mutant:all
.
The Output should look like this:
- Subjects: 6
- Mutations: 97
- Kills: 63
- Runtime: 7.61s
- Killtime: 7.37s
- Overhead: 3.08%
- Coverage: 64.95%
- Alive: 34
Woah! There are 34 mutants alive which our test suite wasn't able to kill. This means that the implementation could be changed, but the tests won't recognize it.
More concrete? The easiest thing mutant did for example:
Wow, even something that raises an exception is not covered by tests. That's pretty bad, isn't it? (To be fair, since Bob integrates the Statement class, this will be covered, but in isolation it won't, because there are no corresponding tests for Statement.)
Look at the output what mutant change and KILL ALL THE MUTANTS!
Write some specs to kill the mutations on the statement class, or feel free to refactor everything.
Type rake -T
to list all available tasks.