Die Testing Pyramid ist Mike Cohns Modell aus „Succeeding with Agile“ (2009), das eine Testsuite auf drei Schichten verteilt. Viele schnelle, isolierte Unit-Tests bilden die Basis, eine moderate Zahl von Integrationstests die Mitte und wenige End-to-End-Tests die Spitze. Weil untere Ebenen günstiger sind und schneller Feedback liefern, testet man nichts über die UI, was sich isoliert testen lässt.

Testing Pyramid

Details

Vollständiger Name: Testing Pyramid nach Mike Cohn

Kernkonzepte:

Drei Schichten

Unit-Tests (Basis): Viele schnelle, isolierte Tests
Integrationstests (Mitte): Moderate Anzahl, testen Komponenteninteraktion
End-to-End-Tests (Spitze): Wenige, testen komplette User Journeys

Proportionale Verteilung

Mehr Unit-Tests, weniger E2E-Tests

Kosten und Geschwindigkeit

Unit-Tests günstig und schnell, E2E-Tests teuer und langsam

Feedback-Schleifen

Schnelleres Feedback von unteren Ebenen

Anti-Pattern: Eistüte

Zu viele E2E-Tests, zu wenige Unit-Tests

Auf der richtigen Ebene testen

Nicht durch UI testen, was isoliert getestet werden kann

Vertrauensgradient

Balance zwischen Vertrauen und Ausführungsgeschwindigkeit

Schlüsselvertreter

Mike Cohn ("Succeeding with Agile", 2009)

Wann zu verwenden:

Planung der Teststrategie für Projekte
Ausbalancierung von Testtypen in CI/CD-Pipelines
Bewertung bestehender Testsuiten
Anleitung von Team-Testpraktiken

Kritik:

Kent C. Dodds, "Write tests. Not too many. Mostly integration." (2019) — schlägt die Testing Trophy vor: Integrationstests liefern das beste Vertrauen pro Kosten, die unit-lastige Basis der Pyramide optimiere also auf die falsche Metrik
Spotify Engineering, "Testing of Microservices" (2018) — schlägt für Microservices die Honeycomb-Form vor: unit-lastige Suiten koppeln Tests an Implementierungsdetails und zerbrechen beim Refactoring
Die Schichtgrenzen verschwimmen in modernen Stacks — schnelle In-Memory-"Integrationstests" untergraben die Kernannahme der Pyramide, dass höhere Testebenen zwangsläufig langsam und teuer sind