Die Testpyramide von Mike Cohn plädiert für viele schnelle Unit-Tests bei der Entwicklung von Anwendungen. Komplexere und langsamere Integrations- und Systemtests sollen hingegen einen deutlich geringeren Anteil ausmachen. Welche Vorteile hat dieses Konzept?
Automatisierte Tests sind aus der Software-Entwicklung nicht mehr wegzudenken und ihre Einsatzmöglichkeiten sind vielfältig. Doch wann sollte welche Art von Test (Unit, Integration, System, ...) eingesetzt werden? Es braucht eine Teststrategie, um die Vorteile der verschiedenen Varianten auszuschöpfen. Die von Mike Cohn entwickelte Testpyramide liefert eine Strategie zum Testen von Anwendungen.
Vor einem näheren Blick auf die Testpyramide werden zunächst die verschiedenen Testarten kurz vorgestellt. Zur besseren Einordnung werden die Tests anhand der verwendeten Testmethode und des Test-Levels bewertet. Mit Testmethode ist der Box-Ansatz gemeint (White-Box, Gray-Box, Black-Box), welcher den Blickwinkel beschreibt, der bei der Testentwicklung eingenommen wurde. Während beim White-Box-Test die Codestruktur bekannt ist, wird beim Black-Box-Test eine Außenperspektive eingenommen. Die Test-Level gehen hingegen auf den SWEBOK Guide der IEEE zurück und beziehen sich auf den Umfang des geprüften Codes in Unit-, Integration- und System-Tests.
Mit Unit-Tests wird das Verhalten einzelner Komponenten – wie Klassen, Funktionen oder Methoden – überprüft, unter Berücksichtigung der inneren Funktionalität (White-Box-Test). Sie sind einfach zu erstellen und können sehr schnell durchgeführt werden. Ihre Ausführungszeiten liegen meist bei wenigen Millisekunden, selbst umfangreichere Tests dauern nicht länger als 1-2 Minuten.
Integrationstests prüfen die Schnittstelle und das Zusammenspiel zwischen zwei Komponenten. Sie behandeln die zu testende Anwendung in der Regel als Black-Box (Black-Box-Test). Gelegentlich wird auch ein Gray-Box-Test eingesetzt, wenn neben dem Verhalten von Schnittstellen auch interne Abläufe überprüft werden sollen. Die Tests werden so realitätsnah wie möglich in einer produktionsähnlichen Laufzeitumgebung ausgeführt, was die Ausführungszeit deutlich erhöht.
Der Fokus von Systemtests liegt auf dem Verhalten des gesamten Systems. Systemtests können daher als Oberbegriff für UI-Tests und End-to-End-Tests (E2E-Tests) verstanden werden. Da bei diesen Tests ausschließlich das externe Verhalten der Anwendung überprüft wird, handelt es sich um Black-Box-Tests.
Die Testpyramide von Mike Cohn beschreibt ein Konzept zum Einsatz der genannten automatisierten Softwaretests. Die Pyramide besteht aus drei Leveln, aufgebaut nach Einsatzhäufigkeit und Relevanz. Sie ordnet also nicht nur ein, sondern bewertet Unit-Tests, Integrationstests und Systemtests auch.
Die breite Basis der Testpyramide bilden im Idealfall viele schnelle und einfach zu wartende Unit-Tests. So können die meisten Fehler schon in frühen Phasen der Entwicklung entdeckt werden. Auf dem mittleren Level befinden sich die Integrationstests. Sie leisten wertvolle Dienste bei der zielgerichteten Prüfung von kritischen Schnittstellen. Die Ausführungszeiten von Integrationstests sind länger und auch ihre Pflege ist aufwändiger als die von Unit-Tests.
Die Spitze der Pyramide besteht aus langsamen Systemtests, die mitunter sehr wartungsintensiv sind. Systemtests sind sehr hilfreich, um die Funktion der Anwendung als Ganzes zu prüfen. Zum Testen von Verzweigungen im Code sind sie jedoch ungeeignet. Da die Tests des oberen Levels zeitintensiv und somit teuer sind, muss der Einsatz von aufwendigen Systemtests sorgfältig abgewogen werden. Grundsätzlich sollten so viele Tests wie möglich auf den untersten Level (Unit-Tests) verlagert werden. Tritt bei Integrations- oder Systemtests ein Fehler auf, muss dieser nicht nur behoben, sondern auch ein entsprechender Unit-Test geschrieben werden, um ein erneutes Auftreten zu verhindern.
Testframeworks erfreuen sich inzwischen hoher Beliebtheit, verändern jedoch auch den Entwicklungsprozess. In Systemen, in denen nur wenige Unit-Tests bestehen, werden nun durch den Einsatz von Frameworks wie Selenium vor allem System- und Integrationstests geschrieben, wodurch ein Ungleichgewicht entsteht.
Wo eigentlich viele leichtgewichtige Unit-Tests eingesetzt werden sollten, existieren nun etliche komplexe Tests, die teilweise Stunden dauern können. Es findet eine Verlagerung von Unit-Tests zu Integrationstests statt und die Form entspricht nicht mehr einer Pyramide, sondern vielmehr einer Eiswaffel. Daher wird dieser Umstand auch als Ice-Cream Cone Anti-Pattern bezeichnet.
Der Wartungsaufwand ist bei der Eiswaffel höher. Durch steigende Ausführungszeiten der Tests kann es außerdem passieren, dass das Entwicklungsteam die Anwendung nach Codeänderungen seltener testet. Das führt mittelfristig zu mehr Fehlern und längeren Entwicklungszeiten.
Eine Testverteilung in Form der Eiswaffel ist also wenig erstrebenswert. Der Umkehrschluss der Eiswaffel ist jedoch nicht die Testpyramide, sondern die Honigwabe (Testing Honeycomb) mit einem Schwerpunkt bei Integrationstests. Zusätzlich existieren weitere Teststrategien wie der Pokal (The Testing Trophy), der ebenfalls auf Integrationstests setzt und – genau wie die Honigwabe – für wenige Unit-Tests plädiert.
Im Zuge der immer größer werdenden technischen Möglichkeiten wie z. B. einfache E2E-Tests haben sich also auch weitere Testkonzepte entwickelt. Doch egal ob Testpyramide, Honigwabe oder Pokal zum Einsatz kommen: Jede Teststrategie hat ihre Stärken und Schwächen. Der Mix der automatisierten Softwaretests muss zu den jeweiligen Projektanforderungen passen.
Und auch die guten alten manuellen Tests sollten nicht vergessen werden. Manchmal ist es einfacher, drei Minuten von Hand zu testen, als eine Woche mit der Automatisierung des Tests zu verbringen.
Jetzt beim OPEN KNOWLEDGE-Newsletter anmelden und alle sechs Wochen Insider-News und weitere Tipps erhalten.
Bock auf IT? Komm ins Team!
Das gesamte Leistungsangebot findest du hier.
Automatisierte Tests sind aus der Software-Entwicklung nicht mehr wegzudenken und ihre Einsatzmöglichkeiten sind vielfältig. Doch wann sollte welche Art von Test (Unit, Integration, System, ...) eingesetzt werden? Es braucht eine Teststrategie, um die Vorteile der verschiedenen Varianten auszuschöpfen. Die von Mike Cohn entwickelte Testpyramide liefert eine Strategie zum Testen von Anwendungen.
Vor einem näheren Blick auf die Testpyramide werden zunächst die verschiedenen Testarten kurz vorgestellt. Zur besseren Einordnung werden die Tests anhand der verwendeten Testmethode und des Test-Levels bewertet. Mit Testmethode ist der Box-Ansatz gemeint (White-Box, Gray-Box, Black-Box), welcher den Blickwinkel beschreibt, der bei der Testentwicklung eingenommen wurde. Während beim White-Box-Test die Codestruktur bekannt ist, wird beim Black-Box-Test eine Außenperspektive eingenommen. Die Test-Level gehen hingegen auf den SWEBOK Guide der IEEE zurück und beziehen sich auf den Umfang des geprüften Codes in Unit-, Integration- und System-Tests.
Mit Unit-Tests wird das Verhalten einzelner Komponenten – wie Klassen, Funktionen oder Methoden – überprüft, unter Berücksichtigung der inneren Funktionalität (White-Box-Test). Sie sind einfach zu erstellen und können sehr schnell durchgeführt werden. Ihre Ausführungszeiten liegen meist bei wenigen Millisekunden, selbst umfangreichere Tests dauern nicht länger als 1-2 Minuten.
Integrationstests prüfen die Schnittstelle und das Zusammenspiel zwischen zwei Komponenten. Sie behandeln die zu testende Anwendung in der Regel als Black-Box (Black-Box-Test). Gelegentlich wird auch ein Gray-Box-Test eingesetzt, wenn neben dem Verhalten von Schnittstellen auch interne Abläufe überprüft werden sollen. Die Tests werden so realitätsnah wie möglich in einer produktionsähnlichen Laufzeitumgebung ausgeführt, was die Ausführungszeit deutlich erhöht.
Der Fokus von Systemtests liegt auf dem Verhalten des gesamten Systems. Systemtests können daher als Oberbegriff für UI-Tests und End-to-End-Tests (E2E-Tests) verstanden werden. Da bei diesen Tests ausschließlich das externe Verhalten der Anwendung überprüft wird, handelt es sich um Black-Box-Tests.
Die Testpyramide von Mike Cohn beschreibt ein Konzept zum Einsatz der genannten automatisierten Softwaretests. Die Pyramide besteht aus drei Leveln, aufgebaut nach Einsatzhäufigkeit und Relevanz. Sie ordnet also nicht nur ein, sondern bewertet Unit-Tests, Integrationstests und Systemtests auch.
Die breite Basis der Testpyramide bilden im Idealfall viele schnelle und einfach zu wartende Unit-Tests. So können die meisten Fehler schon in frühen Phasen der Entwicklung entdeckt werden. Auf dem mittleren Level befinden sich die Integrationstests. Sie leisten wertvolle Dienste bei der zielgerichteten Prüfung von kritischen Schnittstellen. Die Ausführungszeiten von Integrationstests sind länger und auch ihre Pflege ist aufwändiger als die von Unit-Tests.
Die Spitze der Pyramide besteht aus langsamen Systemtests, die mitunter sehr wartungsintensiv sind. Systemtests sind sehr hilfreich, um die Funktion der Anwendung als Ganzes zu prüfen. Zum Testen von Verzweigungen im Code sind sie jedoch ungeeignet. Da die Tests des oberen Levels zeitintensiv und somit teuer sind, muss der Einsatz von aufwendigen Systemtests sorgfältig abgewogen werden. Grundsätzlich sollten so viele Tests wie möglich auf den untersten Level (Unit-Tests) verlagert werden. Tritt bei Integrations- oder Systemtests ein Fehler auf, muss dieser nicht nur behoben, sondern auch ein entsprechender Unit-Test geschrieben werden, um ein erneutes Auftreten zu verhindern.
Testframeworks erfreuen sich inzwischen hoher Beliebtheit, verändern jedoch auch den Entwicklungsprozess. In Systemen, in denen nur wenige Unit-Tests bestehen, werden nun durch den Einsatz von Frameworks wie Selenium vor allem System- und Integrationstests geschrieben, wodurch ein Ungleichgewicht entsteht.
Wo eigentlich viele leichtgewichtige Unit-Tests eingesetzt werden sollten, existieren nun etliche komplexe Tests, die teilweise Stunden dauern können. Es findet eine Verlagerung von Unit-Tests zu Integrationstests statt und die Form entspricht nicht mehr einer Pyramide, sondern vielmehr einer Eiswaffel. Daher wird dieser Umstand auch als Ice-Cream Cone Anti-Pattern bezeichnet.
Der Wartungsaufwand ist bei der Eiswaffel höher. Durch steigende Ausführungszeiten der Tests kann es außerdem passieren, dass das Entwicklungsteam die Anwendung nach Codeänderungen seltener testet. Das führt mittelfristig zu mehr Fehlern und längeren Entwicklungszeiten.
Eine Testverteilung in Form der Eiswaffel ist also wenig erstrebenswert. Der Umkehrschluss der Eiswaffel ist jedoch nicht die Testpyramide, sondern die Honigwabe (Testing Honeycomb) mit einem Schwerpunkt bei Integrationstests. Zusätzlich existieren weitere Teststrategien wie der Pokal (The Testing Trophy), der ebenfalls auf Integrationstests setzt und – genau wie die Honigwabe – für wenige Unit-Tests plädiert.
Im Zuge der immer größer werdenden technischen Möglichkeiten wie z. B. einfache E2E-Tests haben sich also auch weitere Testkonzepte entwickelt. Doch egal ob Testpyramide, Honigwabe oder Pokal zum Einsatz kommen: Jede Teststrategie hat ihre Stärken und Schwächen. Der Mix der automatisierten Softwaretests muss zu den jeweiligen Projektanforderungen passen.
Und auch die guten alten manuellen Tests sollten nicht vergessen werden. Manchmal ist es einfacher, drei Minuten von Hand zu testen, als eine Woche mit der Automatisierung des Tests zu verbringen.
Jetzt beim OPEN KNOWLEDGE-Newsletter anmelden und alle sechs Wochen Insider-News und weitere Tipps erhalten.
Bock auf IT? Komm ins Team!
Das gesamte Leistungsangebot findest du hier.
