27. November 2015 | 3 min lesezeit

Die Test-Pyramide

Das Konzept der Test-Pyramide wurde von Mike Cohn entwickelt. Die Kernaussage besteht darin, dass für eine sinnvoll getestete Anwendung mehr einfache und schnelle Unit-Tests als komplexe und langsamere Integration oder System-Tests existieren sollen. Doch was bedeutest das genau?

Software-Entwicklung ohne automatisierte Tests ist heute nur noch schwer vorstellbar. Es gibt sie in unterschiedlichen Varianten (Unit, Integration, System, …) und für unterschiedliche Zwecke (Funktion, Kompatibilität, Regression, …). Sie alle bieten gewisse Vorteile, bringen aber auch gewisse Kosten mit sich.

Um die unterschiedlichen Tests besser einordnen zu können, bewertet man sie anhand der verwendeten Testmethode und des Test-Levels. Die Testmethode bezieht sich auf den Box-Ansatz (White-Box, Black-Box, Gray-Box) und beschreibt den Blickwinkel des Entwicklers bei der Testentwicklung. Die Einordnung in Test-Level geht auf den SWEBOK Guide der IEEE zurück und gruppiert Tests anhand des Umfang an geprüften Code in Unit-, Integration- und System-Test.

Unit-Tests prüfen das Verhalten einer einzelnen Klasse unter Berücksichtigung der internen Funktionalität (White-Box-Test) und zeichnen sich durch extrem kurze Ausführungszeiten von wenigen Millisekunden aus, so dass sich auch sehr große Testsuiten in maximal in 1-2 Minuten ausführen lassen sollten. Für eine einzelne Funktion können mehrere Testfälle existieren, um Ausnahmen, Grenzen oder mehrere Zweige (Code Branch, z.B. eine if-else Anweisung) zu prüfen.

Eine genaue Abgrenzung zwischen Integration- und System-Test ist nicht immer einfach, da der Begriff Integration-Test oftmals auch für System-Tests verwendet wird. Während man unter einem Integration-Test die Prüfung der Schnittstelle zwischen zwei Komponenten beschreibt, werden unter System-Tests sowohl UI-Tests als auch End-To-End-Tests zusammengefasst. Letztere prüfen den kompletten Durchstich bis zur Datenbank. Integration- wie auch System-Tests behandeln die zu testende Anwendung i.d.R. als Black-Box (Black-Box-Test), in manchen Fällen werden sie auch als Gray-Box-Test realisiert, wenn neben dem Verhalten der Schnittstelle auch der interne Zustand verifiziert werden soll. Um möglich realistisch testen zu können, werden die Tests in einer produktionsähnlichen Laufzeitumgebung ausgeführt, was allerdings die Ausführungszeit spürbar erhöht.

Die von Mike Cohn entwickelte Test-Pyramide besteht aus drei Ebenen, die den drei vorgestellten Test-Leveln entsprechen. Mit Hilfe der Pyramide soll der richtige Mix unterschiedlicher Tests verdeutlicht werden, den es bei der Entwicklung einer Teststrategie zu finden gilt. Im Idealfall bildet ein hoher Anteil an schnellen und einfach zu wartenden Unit-Test das breite wie solide Fundament der Test-Pyramide. Integration-Tests bilden die mittlere Ebene der Test-Pyramide. Sie haben i.d.R. längere Ausführungszeiten und sind aufwendiger zu Pflegen, daher sollten sie zielgerichtet zur Prüfung kritischer Schnittstellen eingesetzt werden. Die Spitze der Test-Pyramide bilden die vergleichweise langsamen und mitunter wartungsintensiven System-Tests. Diese ermöglichen einen guten Einblick ob die Anwendung in Gänze funktionert, eignen sich aber keinesfalls zum Testen aller möglichen Zweige im Code. Daher sollte ihre Anzahl auch minimiert und so viele Tests wie möglich auf die unteren Ebenen verlagert werden. Wird trotz guter Testabdeckung ein Fehler durch einen Integration- oder System-Test erkannt, ist dieser nicht nur zu fixen, es sollte auch ein zusätzlicher Unit-Tests erstellt werden um sicherzustellen, dass der Fehler nicht erneut auftritt.

Die Test-Pyramide weißt indirekt auf ein Problem hin, dass mit der wachsenden Popularität von Testframeworks wie Arquillian und Selenium verstärkt zu beobachten ist. Wurden in der Vergangenheit oftmals keine Tests erstellt, haben die die Frameworks einem massiven Anstieg an System-Tests, insbesondere End-To-End-Tests und UI-Tests, befeuert. Statt vieler schneller Unit-Tests existiert nun eine große Anzahl komplexer Tests, deren Ausführung mitunter Stunden dauern kann. Die Verteilung der Tests entspricht nun nicht mehr der Form einer Pyramide sondern eher einer Eiswaffel, weshalb man diesen Umstand auch als das Ice-Cream Cone Anti-Pattern bezeichnet.

Neben dem zunehmenden Wartungsaufwand kann dies sogar einen negativen Effekt auf die Entwicklungsperformanz haben. Mit steigender Ausführungsdauer sinkt die Bereitschaft des Entwicklungsteams, Tests wiederholt auszuführen und die Korrektheit der gesamten Anwendung nach einer Codeänderung direkt zu prüfen, was mittelfristig wieder zu mehr Fehlern und längeren Entwicklungszeiten führt.

Zu guter Letzt sollte man auch manuelle Tests nicht völlig außer Acht lassen. Natürlich widersprechen sie grundlegend dem Konzept automatisierter Tests, allerdings gilt es auch hier abzuwägen. Ein manueller Test der gelegentlich drei Minuten in Anspruch nimmt, dessen Automatisierung jedoch eine Woche erfordert, sollte vielleicht auch weiterhin manuell erfolgen.


Keine Kommentare

Kontakt

OPEN KNOWLEDGE GmbH

Standort Oldenburg:
Poststraße 1, 26122 Oldenburg

Standort Essen:
II. Hagen 7, 45127 Essen