Eine Wissenschaft für sich im Test-Driven Development ist die Frage, wie jede einzelne Funktion getestet werden muss: Sind die Tests vollständig, hat man jeden Spezialfall bedacht? Hat man es zu gut gemeint und eine schwer überschaubare, redundante Testsuite geschaffen?
Einen recht ungewöhnlichen Weg zur Beantwortung der ersten Frage geht Markus Schirp. Sein Gem Mutant betrachtet Code und die zugehörigen, grünen Tests. Es verändert nun immer wieder bestimmte Teile des Applikations-Codes (nicht die Tests) und prüft, ob die Tests dadurch fehlschlagen. Tun sie dies nicht lässt sich schlussfolgern, dass diese Stellen des Codes nicht vollständig durch Tests abgedeckt oder tot sind.
Die Code-Änderungen sind dabei vollautomatisch. Ifs werden durch Unless ersetzt, boolsche Default-Werte von Argumenten werden negiert oder ganze Statements weggelassen. Solange die Tests dadurch fehlschlagen ist es egal wie viel Unsinn sich hieraus ergibt.
Der Ansatz klingt auf jeden Fall interessant und erscheint um einiges aussagekräftiger als die üblichen Code-Coverage-Statistiken. Ob er wirklich praxistauglich ist kann ich aufgrund mangelnder Erfahrung nicht beurteilen. Im Weg steht leider auch der etwas sperrige Einstieg. Ich konnte etwa keine Beispiele finden wie man Code mit Rails-Abhängigkeiten testet – und von diesem Code habe ich eine Menge. Ein Gem Mutant-Rails gibt es zwar schon, ist aber mit einem entmutigenden „This gem does not yet work“ überschrieben. Aber der Kurs scheint zu stimmen.
Auf der Rails-Conf 2014 gab es einen Vortrag zu Mutant. Dieser kratzt leider nur an der Oberfläche, zeigt aber immerhin ein Live-Beispiel.