© Excellent backgrounds/Shutterstock.com
Java Magazin
Teststile: Schwierige Tests mit Doubles

Teststile: Schwierige Tests mit Doubles

Fake it till you make it: So könnte man den zweiten Teil dieser Serie auf den Punkt bringen. Die Rede ist von Testdoubles, die als Platzhalter für echte Objekte in Unit Tests verwendet werden können, um bestimmte Programmeinheiten isoliert zu testen oder die Interaktion zwischen Objekten in die Verifikation einzubeziehen. Den Einsatz dieser Testdoubles und unterschiedliche Teststile beschreibt der folgende Beitrag.

Kai Spichale


Ein Unit Test sollte jeweils nur einen Aspekt in Isolation testen und sich auf kleine Programmeinheiten beziehen. Diese Programmeinheiten reichen im Idealfall von einzelnen Methoden bis hin zu wenigen zusammenhängenden Klassen. Doch leider existieren in einer durchschnittlich komplexen Anwendung so viele Abhängigkeiten, dass kaum ein Objekt ohne Mitwirkung anderer Objekte auskommt.

ArtikelserieTeil 1: Eigenschaften von TDD und BDD, Best Practices für Unit TestsTeil 2: TeststileTeil 3: Test- und Build-Automatisierung

Bei einem pragmatischen Bottom-up-Ansatz könnte man zunächst Objekte der untersten Schicht testen. Die getesteten Objekte werden anschließend mit der nächsthöheren Schicht integriert, um auch diese zu testen. Der Prozess wird wiederholt, bis schließlich auch die oberste Schicht der Objekthierarchie an der Reihe war. Bei einem Top-down-Vorgehen − geläufig ist auch die Bezeichnung outside-in − würde man die Entwicklung mit dem Test des UI beginnen, eventuell Benutzerinteraktionen einbeziehen und sich Schicht für Schicht nach unten arbeiten. Dieses Vorgehen setzt in Tests das Vorhandensein von Objekten in unteren Schichten voraus, die noch nicht entwickelt wurden und deren Schnittstellen erst durch Tests identifiziert werden sollen. Diese Objekte können durch Testdoubles ersetzt werden. Der Begriff Testdoubles [1] ist die allgemeine Bezeichnung für Objekte, die zu Testzwecken Objekte des produktiven Codes ersetzen. Mit dem Bottom-up-Vorgehen könnte man theoretisch auf Testdoubles verzichten. Praktisch werden jedoch in beiden Varianten der testgetriebenen Entwicklung (Test-driven Development, TDD) Doubles eingesetzt.

Die wohl geläufigsten Varianten dieser Testdoubles sind Test-Stubs und Mock-Objekte. Die Unterschiede dieser Testdoubletypen werden in den nachfolgenden Beispielen dieses Artikels erläutert. Ebenfalls werden die Eigenschaften von Verhaltens- und Zustandsverifikation zweier unterschiedlicher Teststile beschrieben.

Typen von TestdoublesFür automatisierte Unit Tests werden häufig Testdoubles eingesetzt. Das sind Objekte, die Teile der produktiven Software ersetzen. Testdoubles verhalten sich wie die echten Objekte des produktiven Codes, basieren jedoch auf einer anderen, i. d. R. einfacheren Implementierung, um die Komplexität von Tests zu reduzieren. Gerald Meszaros [1] unterscheidet folgende Testdoubles:Ein Dummy entspricht dem primitivsten Typ der Testdoubles. Er enthält keine Implementierung und ist vergleichbar mit einem Nullwert, der...

Java Magazin
Teststile: Schwierige Tests mit Doubles

Teststile: Schwierige Tests mit Doubles

Fake it till you make it: So könnte man den zweiten Teil dieser Serie auf den Punkt bringen. Die Rede ist von Testdoubles, die als Platzhalter für echte Objekte in Unit Tests verwendet werden können, um bestimmte Programmeinheiten isoliert zu testen oder die Interaktion zwischen Objekten in die Verifikation einzubeziehen. Den Einsatz dieser Testdoubles und unterschiedliche Teststile beschreibt der folgende Beitrag.

Kai Spichale


Ein Unit Test sollte jeweils nur einen Aspekt in Isolation testen und sich auf kleine Programmeinheiten beziehen. Diese Programmeinheiten reichen im Idealfall von einzelnen Methoden bis hin zu wenigen zusammenhängenden Klassen. Doch leider existieren in einer durchschnittlich komplexen Anwendung so viele Abhängigkeiten, dass kaum ein Objekt ohne Mitwirkung anderer Objekte auskommt.

ArtikelserieTeil 1: Eigenschaften von TDD und BDD, Best Practices für Unit TestsTeil 2: TeststileTeil 3: Test- und Build-Automatisierung

Bei einem pragmatischen Bottom-up-Ansatz könnte man zunächst Objekte der untersten Schicht testen. Die getesteten Objekte werden anschließend mit der nächsthöheren Schicht integriert, um auch diese zu testen. Der Prozess wird wiederholt, bis schließlich auch die oberste Schicht der Objekthierarchie an der Reihe war. Bei einem Top-down-Vorgehen − geläufig ist auch die Bezeichnung outside-in − würde man die Entwicklung mit dem Test des UI beginnen, eventuell Benutzerinteraktionen einbeziehen und sich Schicht für Schicht nach unten arbeiten. Dieses Vorgehen setzt in Tests das Vorhandensein von Objekten in unteren Schichten voraus, die noch nicht entwickelt wurden und deren Schnittstellen erst durch Tests identifiziert werden sollen. Diese Objekte können durch Testdoubles ersetzt werden. Der Begriff Testdoubles [1] ist die allgemeine Bezeichnung für Objekte, die zu Testzwecken Objekte des produktiven Codes ersetzen. Mit dem Bottom-up-Vorgehen könnte man theoretisch auf Testdoubles verzichten. Praktisch werden jedoch in beiden Varianten der testgetriebenen Entwicklung (Test-driven Development, TDD) Doubles eingesetzt.

Die wohl geläufigsten Varianten dieser Testdoubles sind Test-Stubs und Mock-Objekte. Die Unterschiede dieser Testdoubletypen werden in den nachfolgenden Beispielen dieses Artikels erläutert. Ebenfalls werden die Eigenschaften von Verhaltens- und Zustandsverifikation zweier unterschiedlicher Teststile beschrieben.

Typen von TestdoublesFür automatisierte Unit Tests werden häufig Testdoubles eingesetzt. Das sind Objekte, die Teile der produktiven Software ersetzen. Testdoubles verhalten sich wie die echten Objekte des produktiven Codes, basieren jedoch auf einer anderen, i. d. R. einfacheren Implementierung, um die Komplexität von Tests zu reduzieren. Gerald Meszaros [1] unterscheidet folgende Testdoubles:Ein Dummy entspricht dem primitivsten Typ der Testdoubles. Er enthält keine Implementierung und ist vergleichbar mit einem Nullwert, der...

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