© svetabelaya/Shutterstock.com
Mutation Testing mit PIT

Attack of the Java Mutants


Im gleichen Maß, in dem das Schreiben von Tests immer mehr in den Aufgabenbereich von Entwicklern fällt, müssen wir uns vermehrt die Frage stellen, wie wir die Qualität unserer Testsuite messen und bewerten können. Mutation Testing ist in diesem Kontext ein interessantes Tool, das wir zur Entwicklungszeit einsetzen können, um unsere Tests zu verbessern, während wir sie schreiben.

Für viele von uns sind Tests ein ständiger Begleiter im Entwickleralltag und für manche womöglich ein zuverlässiger Partner, der es uns erlaubt, die Kontrolle über unseren Produktionscode zu behalten. So ermöglicht es uns eine gute Testsuite, unseren Code kontinuierlich zu erweitern und einem Refactoring zu unterziehen, ohne dass wir uns Sorgen machen müssen, bestehende Funktionalitäten dabei zunichte zu machen.

Aber wie kann ich beim Refactoring meines Testcodes Sicherheit erhalten? Woher weiß ich, dass ich einer Testsuite trauen kann, wenn ich in ein bestehendes Projekt komme? Wie kann ich sicherstellen, dass ich effektive Tests schreibe? Und woher weiß ich, dass mein Team effektive Tests schreibt?

Zusammenfassend stellt sich uns also die Frage: Wie kann ich die Qualität meiner Testsuite beurteilen? Hier wird als Antwort gerne auf Code Coverage verwiesen (vielleicht auch, weil es sich als Metrik so managerfreundlich in Tools wie SonarQube visualisieren lässt). Es gibt verschiedene Code-Coverage-Kriterien, üblich sind zum Beispiel Line-, Branch- oder Statement-Coverage. Doch diese Coverage sagt letztlich nur aus, welche Teile unseres Codes ausgeführt wurden, aber nicht, welche Teile getestet werden. Code ausführen ist nicht das gleiche wie Code testen. Entsprechend kann Code Coverage uns nur sagen, welcher Code nicht getestet wurde.

Rise of the Mutants

Bereits 1971 veröffentlichte der Student Richard Lipton, bekannt durch seine Pionierarbeit im Bereich des DNA-Computing, das Paper „Fault Diagnosis of Computer Programs“, in dem er erstmalig die Idee äußert, bewusst Bugs in eine zu testende Codebasis einzuführen, um die existierende Testsuite daraufhin zu bewerten, ob sie diesen Bug findet. Da Lipton das Paper während seines Studiums lediglich im Rahmen einer Seminararbeit veröffentlicht hat, ist es sehr schwer, diese Quelle ausfindig zu machen, wenngleich das Paper in vielen anderen akademischen Papers referenziert wird.

Glücklicherweise veröffentlichte Lipton zusammen mit DeMillo und Sayward im IEEE Computer Journal 1978 das Paper „Hints on Test Data Selection: Help for the Pra...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang