© Spirit Boom Cat/Shutterstock.com
Mit Mutation Testing zu sinnvolleren Unit-Tests

Sinnfreies Testing stoppen


Eine Testabdeckung von ≥ 80 Prozent wird heute häufig bei Projektbeginn festgelegt. Im weiteren Verlauf wird sie gerne als Beleg oder Metrik für die aktuelle Qualität der Software herangezogen. Leider haben die dahinterliegenden Tests oft nicht viel mehr Nutzen als diese Zahl zu erzeugen.

Wer kennt es nicht? Man kommt in ein neues Projekt und dem Kunden wurde natürlich qualitative Software versprochen. Über diese wird unter anderem durch eine Metrik der Testabdeckung regelmäßig berichtet (oft auch durch andere Codemetriken, wie sie z. B. durch SonarQube erzeugt werden, aber wir beschränken uns hier auf die Testabdeckung). Diese soll mindestens 80 Prozent betragen – Unternehmensstandard.

Der rührt oft daher, dass das Management mal gehört hat, dass qualitative Software meist eine hohe Testabdeckung hat. Da sich diese so einfach messen lässt, liegt es nahe, hiermit auch die Qualität zu messen. Obwohl es mehrere Definitionen von Testabdeckung gibt (Kasten: „Arten der Testabdeckung“), ist in der Praxis hier meist die Codeabdeckung, Line- oder Branch-Coverage, bezogen auf die Unit-Tests, gemeint.

Arten der Testabdeckung

Testabdeckung kann unterschiedliche Bedeutungen und Interpretationen haben:

  • Fachliche Akzeptanzabdeckung: Abdeckung der fachlichen Anforderungen (und der zugehörigen Akzeptanzkriterien) durch manuelle oder automatische Tests.

  • Codeabdeckung: Abdeckung des Codes durch automatisierte Integrationstests oder Unit-Tests. Dies kann weiter unterschieden werden in:

  • Zeilenabdeckung: Welche Codezeilen werden bei der Testdurchführung ausgeführt?

  • Verzweigungsabdeckung: Zusätzliche Berücksichtigung von Verzweigungsstrukturen

  • Pfadabdeckung: Zusätzlich werden z. B. Schleifen mit 0, 1 und n Durchläufen berücksichtigt

Dies hat meiner Meinung nach zum einen damit zu tun, dass Unit-Tests als Bestandteil der Testautomatisierung das Fundament der Testpyramide bilden (Abb. 1). Zum anderen gibt es mit Tools wie JaCoCo [1] leicht zu integrierende Hilfsmittel, um die Codeabdeckung zu messen.

pater_unit_1.tif_fmt1.jpgAbb. 1: Die Testpyramide

Immerhin werden heute die Unit-Tests zumeist als Standard und Teil der Entwicklung oder auch Qualitätssicherung angesehen, und man muss sich nicht mehr rechtfertigen, wenn man welche schreibt.

Schlechte Qualität trotz hoher Testabdeckung

Nun läuft das Projekt schon eine ganze Weile und reportet regelmäßig eine hohe Testabdeckung. Dennoch häufen sich die Bugs. Sowohl im Bereich der Regression als auch bei Fällen abseits des „Happy Case“. Wie kann das sein? Wir messen doch die Qualität, und die Werte sind gut.

Aus meiner Sicht haben sich in den letzten Jahren einige Faktoren herauskristallisiert, die dieses Phänomen beeinflussen: Zunächst ist die Schlussfolgerung unzulässig, dass hohe Testabdeckung mit guter Qualität gleichzusetzen ist. Daraus, dass qualitative Software oft eine hohe Testabdeckung hat, zu schließen, dass hohe Testabdeckung im Umkehrschluss auch gleich gute Qualität bedeutet, ist so ebenfalls nicht richtig. Das wird durch die Tatsache verschärft, dass zumeist Testabdeckung mit Code Coverage gleichgesetzt wird. Es ist ja auch so leicht, zu messen. In Wahrheit ist es eher so, dass eine Menge von ineinandergreifenden Praktiken – wie zum Beispiel beim Extreme Programming (XP) –, von denen Test-driven Development (TDD) nur eine ist, zu qualitativer Software führen kann. Die Testabdeckung ist hier nur eine sichtbare Begleiterscheinung. Zumal sich hier die Testabdeckung auch über die anderen Definitionen erstreckt.

Oft ist zu diesem Zeitpunkt noch etwas Zusätzliches zu beobachten: Die Entwickler beginnen den Sinn der Unit-Te...

Neugierig geworden? Wir haben diese Angebote für dich:

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