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

Bei der Weiterentwicklung einer Software besteht die Gefahr, durch das Hinzufügen neuer Fähigkeiten unbeabsichtigte Änderungen an vorhandener Funktionalität vorzunehmen. In der testgetriebenen Entwicklung wird jede Änderung an der Funktionalität eines Programms zuvor durch einen neuen Test motiviert. Dieses Buch führt mit praktischen Beispielen in die testgetriebene Entwicklung mit dem frei verfügbaren Regressionstest-Framework JUnit ein und erklärt das Vorgehen bei Akzeptanztests mit FIT.

Klappentext

Testgetriebene Entwicklung geht von einem fehlschlagenden Test aus. Software wird in kleinen sicheren Schritten entwickelt, die abwechselnd darauf abzielen, eine neue Anforderung zu implementieren (den fehlschlagenden Test also zu erfüllen) und das Design zu verbessern (und dabei weiterhin alle Tests zu bestehen).

- Wenn frühes und häufiges Testen wichtig ist, warum schreiben wir nicht für jedes neue Feature zuerst einen automatisierten Test? So können wir während der Entwicklung jederzeit unsere Tests ausführen und lernen, ob unser Code wie gewünscht funktioniert.

- Wenn Design wichtig ist, warum investieren wir dann nicht Tag für Tag darin? So können wir dafür sorgen, dass es möglichst einfach bleibt und nicht mit der Zeit zunehmend degeneriert.

- Wenn Anforderungsdefinition wichtig ist, warum ermöglichen wir unseren Kunden dann nicht, in einem ausführbaren Anforderungsdokument Testfälle für konkrete Anwendungsbeispiele zu spezifizieren? So können wir dokumentieren, welche Funktionalität tatsächlich gefordert ist, und anschließend verifizieren, ob die Erwartungen des Kunden erfüllt werden.

Das Buch führt mit praktischen Beispielen in die Testgetriebene Entwicklung mit den Open-Source-Werkzeugen JUnit und FIT ein.

Aus dem Inhalt:

- Unit Tests mit JUnit - Testgetriebene Programmierung
- Refactoring
- Häufige Integration (CruiseControl u.a.)
- Testfälle schreiben von A bis Z
- Isoliertes Testen durch Stub- und Mock-Objekte
- Akzeptanztests mit FIT (Framework for Integrated Test)

Über den Autor

Frank Westphal studierte Informatik an der FH Wedel. Seit 1998 beschäftigt er sich mit Extreme Programming und beteiligt sich seitdem intensiv an der Verfeinerung der XP-Techniken. Von 1999 bis 2000 war er als Softwareentwickler bei channel one in Hamburg tätig und führte XP im Sommer 1999 in der Produktentwicklung der Intranet-Standardsoftware intraline ein. Seit 2001 arbeitet er als freier Berater und Trainer für Agile Softwareentwicklung, Testen und Refactoring und begleitet mehrere Entwicklungsteams.  


Leseprobe:

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.