Hallo Spaß-Coder.

In den ersten beiden Artikeln der Serie zum Thema Testautomatisierung haben wir uns damit beschäftigt, warum Testautomatisierung sinnvoll ist, und was Unit-Tests sind. Dieser Artikel beschäftigt sich heute mit unterschiedlichen Arten von Unit-Tests und soll euch ein paar Anregungen geben, wozu ihr Unit-Tests noch einsetzen könnt.

 

Welche Arten von Unit-Tests gibt es?

Es gibt eigentlich keine klassische Unterteilung und es sind auch keine „harten“ Unterscheidungsfaktoren, die wir hier auflisten möchten. Vielmehr geht es darum aufzuzeigen, wozu Unit-Tests verwendet werden können. Auf den generellen Zweck und Nutzen von Unit-Tests sind wir bereits ausführlich eingegangen.

 

Lern-Test

Mit Hilfe von Lern-Tests können wir sehr einfach und effizient eine neue Technologie erlernen. Das kann eine neue Programmiersprache, ein neues Sprachfeature oder eine neue Bibliothek sein, die wir einsetzen möchten. Bei Lerntests geht es vor allem darum, Dinge auszuprobieren. Wir überlegen uns Anforderungen – z. B. in Form von User-Stories – und formulieren diese in Testfälle. Dann versuchen wir dies mit der neuen Technologie oder der neuen Bibliothek umzusetzen.

Beispiel:

Mit Java 8 gibt es das tolle neue Feature der Streams. Wie aber funktionieren diese? Was können wir alles damit anstellen. Nach dem Studium der generellen Funktion können wir uns nun überlegen, was wir mit Streams anfangen wollen. Diese Ideen setzen wir nun in Testfälle um und implementieren somit unsere ersten Streams.

Wichtig ist bei Lern-Tests, dass wir diese nicht hinschludern und hinterher nicht einfach wegwerfen, sondern behalten. Damit ändern sie ihre Form zu Boundary-Tests oder Dokumentationstests.

 

Boundary-Test

Unter einem Boundary-Test verstehen wir einen Test, der eine Grenze überprüft. Typischerweise ist dies eine externe Bibliothek. Es kann aber auch eine Komponente eines Kollegen oder eines anderen (Teil-)Teams sein. Mit Hilfe von Boundary-Tests stellen wir fest, ob seine neue Version einer Bibliothek kompatibel zu unserem bisherigen Code ist.

Beispiel:

Unsere Anwendung verwendet eine Bibliothek für eine Rechtschreibprüfung von Text. Nun implementieren wir in Form von Unit-Tests genau diejenigen Funktionen der Bibliothek, die wir auch in unserem Projekt benutzen. Steht nun eine neue Version dieser Bibliothek bereit, können wir diese einbinden und unsere Tests aufrufen. So können wir schnell prüfen, ob die neue Version mit unserer Anwendung zusammen funktioniert oder nicht. Falls nicht sehen wir unmittelbar, wo es Probleme gibt und können diese recht schnell beheben (oder schnell einschätzen, ob sich der Aufwand lohnt).

Boundary-Tests sind sicherlich nicht immer sinnvoll, können aber mitunter nützliche Dienste leisten, vor allem bei wichtigen, zentralen Bibliotheken unserer Anwendung. Auch bei sicherheitsrelevanten Bibliotheken ist es überlegenswert einen Boundary-Test zu schreiben, da diese oft sehr häufig aktualisiert werden. Wenn es eine neue Version gibt, sollte es für uns keinen Grund geben, diese nicht einzusetzen. Diese Unsicherheit schließen wir durch Boundary-Tests aus.

 

Dokumentationstest

Bei Dokumentationstests geht es darum, die Verwendung einer Komponente zu dokumentieren. Mit Hilfe dieser Tests kann ein Entwickler sehr schnell erkennen, wie eine Komponente verwendet werden kann und soll.

 

Beispiel:

Wir haben eine neue Komponente erstellt. Statt nun eine umfangreiche Dokumentation zu verfassen, wie diese funktioniert, können wir auch für alle Anwendungsfälle Unit-Tests schreiben, die das Verhalten erklären. Tests, die das gewünschte Verhalten sicherstellen, haben wir ja sowieso schon erstellt. Vielleicht reicht es, wenn wir diesen noch ein paar erklärende Kommentare hinzufügen und schon weiß ein anderer Programmierer, wie unsere Komponente zu verwenden ist. Auch als Kopiervorlage können diese Tests dienen.

Beispiel 2:

Nehmen wir nochmal das in den Lerntests verwendete Beispiel. Wir haben nun Testfälle für die Verwendung von Streams in Java. Wenn wir diese Tests nun sauber strukturiert, sprechend benannt und ordentlich abgelegt haben, können wir diese nun immer mal wieder als Referenz heranziehen. Stellt sich uns die Frage „Wie war das nochmal?“, finden wir hier sicherlich die Antwort. Und wenn nicht, müssen wir es ohnehin herausfinden und können einen passenden Test ergänzen.

Der Aufwand, Dokumentationstests zu erstellen ist gering (vorausgesetzt, es bestehen bereits ausreichend Unit-Tests), hilft aber vor allem, bei der Arbeit im Team. Es kann aber auch dann hilfreich sein, wenn man selbst eine Bibliothek erstellt und Monate später nochmal in einem anderen Projekt verwenden möchte. Auch hier wird die Frage nach dem „Wie war das nochmal?“ schnell beantwortet.

 

 

Unsere Erfahrung mit den unterschiedlichen Arten

Bislang haben auch wir in erster Linie klassische Unit-Tests geschrieben, welche die Funktionsfähigkeit unserer Komponenten sicherstellen. Hin und wieder setzen wir Lern-Tests ein, um uns mit was neuem zu beschäftigen. Diese haben wir aber meist mit wenig Sorgfalt behandelt, sodass wir sie irgendwann einfach gelöscht haben.

Oft hätten uns vor allem Dokumentationstests und Boundary-Tests geholfen. Wir haben manches Mal eine Bibliothek ausgetauscht um dann mühsam herauszufinden, wo das Problem liegt. Auch zu unseren eigenen Bibliotheken stellen wir uns manchmal die Frage „Wie war das nochmal?“. Wir schauen dann in alten Projekten oder den Quellcode der Bibliothek nach. Schneller wäre hier sicherlich der Blick in die Tests.

 

Zusammenfassung

Es gibt die verschiedensten Gründe, warum man einen Unit-Test erstellen sollte. Er unterstützt neben der Absicherung eines Systems vor ungewollten Änderungen in erster Linie dabei, das System von vorneherein sauber zu designen. Dabei wird die Sicht des „Benutzers“ der Schnittstelle unserer Komponente eingenommen. Darüber hinaus helfen Unit-Tests dabei, eine neue Technik oder Bibliothek kennenzulernen oder unser System vor Änderungen von Außen (an den Abhängigkeiten) zu schützen. Zu guter Letzt bildet es eine elegante Form, unsere Komponente in Form von Beispielen zu dokumentieren. Wir hoffen, euch einige Anregungen gegeben zu haben, um noch mehr aus euren Unit-Tests herauszuholen.

 

Viel Spaß beim Anwenden.

Eure Spaß-Coder

 

 

Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:

• http://www.it-agile.de/wissen/praktiken/agiles-testen/unit-tests/
• Martin, Robert C. Clean Code-Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe. MITP-Verlags GmbH & Co. KG, 2013.