Testgetriebene Entwicklung mit JUnit & FIT - Wie Software änderbar bleibt

7 Testfälle schreiben von A bis Z (S. 127-128)

Das Design der Testfälle verlangt ebenso viel Sorgfalt wie das Design der Anwendung. Um JUnit möglichst effektiv in Ihrer täglichen Arbeit einzusetzen, müssen Sie wissen, wie man effektive Testfälle schreibt. Sie müssen die Prinzipien verstehen, was guten Testcode ausmacht, und noch wichtiger: Sie müssen sich die Codegerüche einprägen für weniger guten Testcode. Sie müssen das alles wissen, weil Sie durch die Testautomatisierung in eine beträchtliche Menge Testcode investieren.

Ich habe in diesem Kapitel das Wissen zusammengetragen, das ich mir als Grundlage gewünscht hätte, als ich meine ersten JUnit-Tests zu schreiben begann. Die diskutierten Punkte gehen dabei von allgemein anerkannten Testmustern bis hin zu JUnit-Idiomen, die bedingt sind durch die Architektur des Test-Frameworks. Das Schreiben dieses Kapitels hat mir ganz besonderen Spaß gemacht, weil es viele wichtige Themen anspricht, die teils zusammenspielen und teils für sich stehen. Ich hoffe, Ihnen geht es ähnlich beim Lesen der Tipps und Tricks!

7.1 Aufbau von Testfällen

Fangen wir damit an, wie JUnit-Testfälle aufgebaut werden. Was oft zur Verwirrung führt: Testfallklassen sind immer um ihre Test-Fixture orientiert. Wenn wir anfangs auch meist für jede Anwendungsklasse eine Testfallklasse aufbauen, ist ein 1:1-Verhältnis nicht zwingend. Anwendungsklassen verlangen manchmal mehrere Testfallklassen und Testfallklassen testen manchmal auch mehrere Anwendungsklassen in Interaktion.

Wie viele Testfallklassen wir erhalten, ist allein eine Frage, wie wir unsere Test-Fixture aufbauen, wie viele verschiedene Fixtures wir testen und wie wir den gemeinsamen Setup-Code faktorisieren. Testfallmethoden stehen nur zusammen in einer Testfallklasse, weil sie sich gemeinsame Fixture-Objekte teilen. Die Klasse TestCase ist ein Mechanismus, um Testcode effektiv wiederverwenden zu können.

Robert Wenner zeichnete im Review zu diesem Buch folgendes Bild: Meistens ergibt sich auch ein logischer Zusammenhang. Zum Beispiel testet eine Testklasse alles zur Interaktion von Äpfeln mit Obstkörben und hat in ihrer Fixture ein Apfel- und ein Obstkorb- Objekt. Eine andere Fixture testet Äpfel und Birnen, beinhaltet also ein Apfel- und Birne-Objekt, aber kein Korb-Objekt.

Die Fixture ist demnach die Unit im Unit Test. Aus diesem Grund steht am Anfang immer die Frage: Was ist die isoliert zu testende Unit? Nur wenn diese Frage geklärt ist, können wir eine passende Fixture aufbauen.

Der strukturelle Aufbau von Testfällen ist immer gleich:

1. Fixture-Objekte erzeugen und in den Ausgangszustand bringen
2. Methoden der Objekte exerzieren
3. Erwartete und tatsächliche Resultate vergleichen

Häufig können wir für neue Testfallmethoden direkt eine existierende Fixture wiederverwenden. Passt keine der bestehenden Test-Fixtures, müssen wir zweifellos eine neue Testfallklasse aufbauen: Wenn sich die Testfallmethoden einer Testfallklasse nicht einhellig ihr Setup teilen können, zeugt dies von einem Codegeruch, der uns eine neue Fixture extrahieren lässt. Mit der Zeit kristallisieren sich auf diese Weise neue weiterverwendbare Fixtures heraus.

Oft gibt uns auch das Präfix oder Suffix der Namen im Programm einen Hinweis zum Refactoring: Würden wir in einer Testfallklasse TopTenTest zum Beispiel die drei Testfälle testSortingWithNoRentals, testTrimmingWithNoRentals und testListingWithNoRentals schreiben, stehen die Sterne eher für eine neue Testklasse EmptyTopTenTest und drei Testfälle mit Namen testSorting, testTrimming und testListing.

Das Herausfaktorisieren von Testfällen mit gemeinsamem Fixture- Code soll so für verbesserte Übersicht sorgen. Das erscheint zunächst nicht intuitiv: Warum nicht den Testcode, der eine Anwendungsklasse betrifft, in einer korrespondierenden Testklasse anhäufen? Testfälle sollen schließlich möglichst einfach der getesteten Klasse zuordenbar sein, oder nicht? Die Frage ist beantwortet, indem Sie sich vorstellen, TestCase in TestFixture umzubenennen, was eigentlich korrekt wäre. Probleme entstehen bei erzwungener 1:1-Beziehung mit langem, unübersichtlichem, teils unnützem oder auch zu duplizierendem Setup- Code. Übersicht in einer 1:n-Beziehung lässt sich dagegen über Namen erreichen: Benennen Sie Ihre Testfallklassen immer nach der Klasse, die Sie vorrangig testen. Benutzen Sie dann zur Navigation im Code die Möglichkeiten moderner Klassenbrowser, mit denen man leicht die Deklarationen, Referenzen u.Ä. zu jeder Klasse aufspüren kann.