Testpyramide

Die Testpyramide ist eine Richtlinie dafür, wie automatisierte Tests auf die Ebenen verteilt werden. Die breite Basis bilden Unit-Tests, die schnell, günstig und präzise sind. In der Mitte liegen Integrations- oder Servicetests. Die schmale Spitze sind End-to-End-Tests über die UI, die das realistischste Vertrauen geben, aber am langsamsten und fragilsten sind. Die von Mike Cohn bekannt gemachte Idee lautet, jede Prüfung auf die niedrigste Ebene zu verlagern, auf der das Problem noch gefunden werden kann.

Beispiel

Nehmen Sie die Regel: „Bestellungen über 100 $ werden versandkostenfrei geliefert“.

• Unit: Testen Sie die Funktion für die Versandkosten mit 99,99 $, 100,00 $ und 100,01 $. Jeweils Millisekunden, kein Browser.
• Integration/API: Rufen Sie POST /orders mit einem Warenkorb über 120 $ auf und prüfen Sie, dass die Antwort shipping: 0 enthält. Das belegt, dass die Regel im Dienst verdrahtet ist.
• End-to-End: ein einziger UI-Test, der einen qualifizierenden Warenkorb bestellt und auf der Bestätigungsseite „Kostenloser Versand“ sieht.

Sie brauchen keine zehn UI-Tests für die Grenzwerte. Die Unit-Tests belegen die Arithmetik bereits.

Warum die Form wichtig ist

Tests auf höheren Ebenen berühren mehr Komponenten, daher verrät Ihnen ein Fehlschlag weniger darüber, wo der Bug steckt. Sie benötigen außerdem Browser, Umgebungen und Testdaten, was sie langsamer und anfälliger für Flakiness macht. Eine Suite, die überwiegend aus UI-Tests besteht (das Anti-Pattern „Eistüte“, englisch Ice-Cream Cone), läuft stundenlang, schlägt aus Gründen fehl, die nichts mit der Änderung zu tun haben, und wird ignoriert.

Kritik und Alternativen

Die Pyramide ist eine Heuristik, keine Quote. Alternativen wie die „Testing Trophy“ legen mehr Gewicht auf Integrationstests, mit dem Argument, dass stark gemockte Unit-Tests bestehen können, während das echte System kaputt ist. Beide Modelle sind sich im Wesentlichen einig: Halten Sie langsame, breite UI-Tests gering an der Zahl und auf kritische User Journeys fokussiert, und beziehen Sie den Großteil Ihres Vertrauens aus schnelleren Schichten. Wählen Sie die Gewichtung danach, woher Ihre Bugs tatsächlich kommen, nicht nach einem festen Verhältnis.