© Arak Rattanawijittakorn/Shutterstock.com
Java Magazin
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.

Karsten Sitterberg


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.

ArtikelserieTeil 1: Testing-Methoden und -Technologien im ÜberblickTeil 2: Komponenten und Unit-Tests für BrowseranwendungenTeil 3: Integrationstests und Ende-zu-Ende-Tests in der PraxisTeil 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.

Abb. 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 (Mock Backend), sodass hier eine Differenzierung schwierig ist: Ein Test von (SPA-seitigen) UI Services alleine kann durch Unittests erfolgen, ein Integrationstest benötigt jedoch sowohl UI-Komponenten als auch UI Services, die wiederum in der Regel ein Backend voraussetzen. Beispiele für die Verwendung von UI Services in Browseranwendungen sind die bereits erwähnte Zustandshaltung, Berechnungen oder Logikanteile des Frontends. Konkret könnte eine solche UI-Logik die Herleitung der zu verwendenden Hintergrundfarbe für ein Issue sei...

Java Magazin
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.

Karsten Sitterberg


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.

ArtikelserieTeil 1: Testing-Methoden und -Technologien im ÜberblickTeil 2: Komponenten und Unit-Tests für BrowseranwendungenTeil 3: Integrationstests und Ende-zu-Ende-Tests in der PraxisTeil 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.

Abb. 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 (Mock Backend), sodass hier eine Differenzierung schwierig ist: Ein Test von (SPA-seitigen) UI Services alleine kann durch Unittests erfolgen, ein Integrationstest benötigt jedoch sowohl UI-Komponenten als auch UI Services, die wiederum in der Regel ein Backend voraussetzen. Beispiele für die Verwendung von UI Services in Browseranwendungen sind die bereits erwähnte Zustandshaltung, Berechnungen oder Logikanteile des Frontends. Konkret könnte eine solche UI-Logik die Herleitung der zu verwendenden Hintergrundfarbe für ein Issue sei...

Neugierig geworden?


   
Loading...

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