Was ist die Testpyramide, und passt sie noch zu der Art, wie Software heute gebaut wird?

Die Pyramide sagt: viele schnelle Unit-Tests, weniger Integrationstests und eine kleine Zahl End-to-End-Tests, weil Kosten und Flakiness nach oben hin steigen, während die Feedback-Geschwindigkeit sinkt. Als Kostenmodell gilt sie weiterhin. Verändert hat sich, dass bei verteilten Services die mittlere Schicht mehr zählt, Contract- und Integrationstests also oft einen größeren Anteil verdienen, als die klassische Form nahelegt.

Die Form kommt aus der Ökonomie. Ein Unit-Test läuft in Millisekunden, schlägt aus genau einem Grund fehl und lügt dich fast nie an. Ein End-to-End-Test läuft Minuten, hängt an einem Browser, einem Netzwerk und sechs Services, und wenn er rot wird, verbringst du zwanzig Minuten damit herauszufinden, ob das Produkt kaputt ist oder die Umgebung. Also willst du viele von den billigen und nur so viele von den teuren, wie nötig sind, um zu belegen, dass die Teile zusammenhängen. Wo ich die klassische Form biegen sehe, ist bei verteilten Systemen. Ist ein Service überwiegend Orchestrierung, testet ein schweres Unit-Testing nur deine eigenen Mocks, also schiebe ich Gewicht in Integrations- und Contract-Tests, was eine Form näher an einer Raute ergibt. Meine Regel fürs Platzieren eines Tests ist zu fragen, was das Kleinste ist, das dieses Verhalten brechen könnte, und auf dieser Ebene zu testen. Ist das Risiko eine Berechnung, dann Unit. Ist das Risiko, dass zwei Services sich über einen Payload uneinig sind, dann Contract. End-to-End behalte ich für eine Handvoll Journeys, die niemals still brechen dürfen.