© Arak Rattanawijittakorn/Shutterstock.com
Teil 3: Integrationstests und Ende-zu-Ende-Tests in der Praxis

Von Anfang bis Ende


Im vorigen Artikel der Serie haben wir uns mit Tests auf der Komponentenebene befasst. Diese befinden sich in der Testpyramide weit unten, laufen schnell durch und weisen einen hohen Isolationsgrad auf. Zudem stellen sie die breite Masse dar, und man sollte auf sie am allerwenigsten verzichten. Leider findet man mit ihrer Hilfe nicht alle potenziellen Fehler in einer Anwendung. Das liegt daran, dass eine typische Anwendung einen komplexen Zustand aufweist, der häufig in unterschiedlichen Komponenten materialisiert ist.

Zu diesem verteilten Zustand kommt nun auch noch das Zusammenspiel mehrerer Komponenten, die ihrerseits das eigene Verhalten auf Basis des Zustands anpassen können oder Einfluss auf den Zustand nehmen.

Ein relativ einfaches Beispiel für diesen Zusammenhang ist ein Datumsfeld in der Anwendung. In das Feld kann ein Datum eingetragen werden. Andererseits kann ein Datum dort auch angezeigt werden, wenn es (vor-)ausgewählt wurde. Kommt als alternatives Eingabeverfahren noch ein Kalender-Datepicker dazu, der seinerseits sowohl Eingabe als auch Anzeige umsetzt, kann es zu Wechselwirkungen kommen, die zu einer fehlerhaften Datumsauswahl führen.

Artikelserie

Teil 1: Testing-Methoden und -Technologien im Überblick

Teil 2: Komponenten und Unit-Tests für Browseranwendungen

Teil 3: Integrationstests und Ende-zu-Ende-Tests in der Praxis

Teil 4: Erweiterte Vorgehensweisen: Tests für besondere Anwendungsfälle

Es ist also leicht zu sehen, dass das Testen von Komponenten in Isolation nur drei Viertel der Miete ausmacht – wir benötigen noch Integrationstests bzw. Ende-zu-Ende-Tests. Bei Integrationstests werden umfangreichere Teile der Anwendung und ihr Zusammenspiel, jedoch nicht die gesamte Anwendung mit Umsystemen getestet. Wir befinden uns damit eine Stufe höher auf der Testpyramide. Bei klassischen Webanwendungen sind solche Integrationstests – komplett ohne UI – sehr einfach möglich. So müssen nicht unbedingt alle durch die Anwendung aufgerufenen Umsysteme (Microservices, Messaging) mit einbezogen werden, um sinnvolle Integrationstests zu erstellen. Typischerweise wird jedoch die Service-Schicht innerhalb der Anwendung mit getestet. Der Aufbau einer klassischen Webanwendung ist in Abbildung 1 links dargestellt.

sitterberg_test_driven_3_1.tif_fmt1.jpgAbb. 1: Grundsätzlicher Aufbau klassischer Webanwendungen (links), in der Regel mit SPA als Frontend (rechts)

Bei Browseranwendungen mit einer SPA-Architektur unterscheiden sich Integrationstests von Ende-zu-Ende-Tests lediglich in Nuancen (Mo...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang