Abdeckung ist nützlich, weil sie zeigt, wo Tests nicht durchgeführt wurden. Sie wird irreführend, wenn Teams sie als Beweis dafür betrachten, dass das System sicher ist.
Sie können die Zeilenabdeckung sehr hoch treiben und dennoch die Verhaltensweisen verpassen, die tatsächlich dem Geschäft schaden:
- Autorisierungsfehler
- Parallelitätsfehler
- Integrationsstörungen
- Randfälle im Anwendungsbereich
Warum Abdeckung Irreführt
Abdeckung beantwortet eine enge Frage: Wurde dieser Code während eines Testdurchlaufs ausgeführt?
Es beantwortet nicht:
- Wurde die richtige Assertion gemacht?
- Wurde der gefährliche Zweig unter realistischen Bedingungen ausgeübt?
- Hat sich das externe System korrekt verhalten?
Ein Zahlungsdienst kann eine Abdeckung von 95 % erreichen und dennoch doppelte Belastungen verursachen, wenn niemand das Verhalten bei Wiederholungen mit dem richtigen Domänenvertrag getestet hat.
Bessere Testperspektive
Eine gute Teststrategie beginnt mit Risiko, nicht mit Prozentsätzen:
- Einheitstests für zentrale Entscheidungslogik
- Integrationstests für externe Grenzen
- Szenariotests für Geschäftsregeln und Fehlermodi
- eine kleinere Anzahl von End-to-End-Tests für kritische Abläufe
Abdeckung ist weiterhin nützlich als Karte. Sie hilft, blinde Flecken aufzudecken. Sie ist nur nicht das Qualitätsurteil an sich.
Bessere Regel
Verwenden Sie die Abdeckung, um zu fragen: "Welchen Code üben wir nicht aus?" Verwenden Sie sie nicht, um zu behaupten: "Das System ist sicher."
Weiterführende Lektüre