Die Testpyramide: welcher Test auf welche Ebene gehört

Worum es geht

Die Testpyramide ist laut Fowlers Bliki-Eintrag vor allem durch Mike Cohn bekannt geworden, der sie 2009 in «Succeeding with Agile» beschrieb. Sie ordnet automatisierte Tests in Ebenen: unten viele Unit-Tests, die eine Einheit isoliert und in Millisekunden prüfen; in der Mitte Integrationstests, die echte Nachbarn wie Datenbank oder Dateisystem einbeziehen; oben wenige Ende-zu-Ende-Tests, die das ganze System über seine öffentliche Schnittstelle bedienen. Nach oben steigen Kosten und Laufzeit, nach unten Genauigkeit und Geschwindigkeit. Fowler nennt die umgekehrte Form – ein dicker Kopf aus Oberflächentests, fast keine Basis – die Eistüte («ice-cream cone»). Der Artikel «The Practical Test Pyramid» auf derselben Website führt die Ebenen an einem Beispiel-Microservice durch.

Warum es wichtig ist

Jede Ebene tauscht Realitätsnähe gegen Diagnosewert. Ein gescheiterter Unit-Test benennt die Funktion, ein gescheiterter Ende-zu-Ende-Test benennt das System und lässt die Suche erst beginnen. Suiten mit zu vielen langsamen Tests laufen selten, flackern häufiger und werden nach und nach ignoriert; die Pyramide hält die Rückmeldung schnell genug, dass Entwicklerinnen und Agenten nach jeder kleinen Änderung testen.

So wird es angewendet

• Logik in Einheiten legen, die ohne Infrastruktur prüfbar sind (reine Funktionen, Klassen mit eingespritzten Abhängigkeiten), und sie an der Basis erschöpfend testen, auch Grenz- und Fehlerfälle.
• Nahtstellen – Abfragen, HTTP-Handler, Serialisierung, Warteschlangen – in der Mitte gegen echte Abhängigkeiten in Containern prüfen, nicht gegen Attrappen der Datenbank.
• Ende-zu-Ende nur die wenigen Abläufe, deren Ausfall das Geschäft trifft (Anmeldung, Kauf, Export), und diese auf dem Integrationszweig statt bei jedem Commit.
• Scheitert ein Ende-zu-Ende-Test, denselben Fehler zusätzlich mit einem tieferliegenden Test nachstellen, der ihn künftig schneller findet.
• Die Laufzeit der Basis beobachten; wächst sie über Sekunden hinaus, lohnt die Suche nach Integrationstests, die als Unit-Tests getarnt sind.

Stolpersteine

Unit-Tests, die alles durch Attrappen ersetzen, prüfen die Attrappen. Integrationstests mit geteiltem veränderlichem Zustand werden reihenfolgeabhängig. Die Pyramide beschreibt Verhältnisse, keine Stückzahlen; ein kleiner Dienst kann flach und trotzdem gut getestet sein. Fowler selbst merkt an, dass die Annahme «breite Tests sind teuer, langsam und brüchig» meist, aber nicht immer gilt.