Unit-Tests

Unit-Tests (=Komponententests) überprüfen, ob die von den Entwicklern geschriebenen Komponenten so arbeiten, wie diese es beabsichtigen. In agilen Methoden wird zur Qualitätssicherung eine sehr häufige Ausführung der Komponententests angestrebt. Das lässt sich nur erreichen, wenn die Tests vollständig automatisiert vorliegen, sie also selbst ein Programm sind, dessen Ausführung nicht mehr Aufwand als einen Knopfdruck erfordert. Dabei ist es üblich (aber nicht zwingend notwendig), dass der Test in der gleichen Sprache wie das Testobjekt geschrieben wird. In der agilen Softwareentwicklung wird im Rahmen der testgetriebenen Entwicklung und des Refactorings massiver Gebrauch von Komponententests gemacht.

Die Rolle, die Unit-Tests in agiler Softwareentwicklung spielen, unterscheidet sich maßgeblich von der Rolle, die sie in klassischen Vorgehensweisen spielen. So dienen sie zum Zeitpunkt ihrer Erstellung im Rahmen der testgetriebenen Entwicklung eher dazu, das Design der Software zu steuern, als Defekte zu finden. Im Rahmen des inkrementellen Entwurfs sind sie unverzichtbar, um auch langfristig änderbaren Code zu behalten. So bilden sie eine wichtige Voraussetzung für Refactorings. Dank der Tests werden versehentliche Änderungen des Verhaltens auf Knopfdruck aufgedeckt. Auch wenn ein bestehendes System um neue Features erweitert werden, helfen Unit-Tests: So decken sie unbeabsichtigte Fernwirkungen der neuen Funktionen auf bereits bestehende Systemteile auf. Darüber hinaus helfen sie auch, das System zu dokumentieren, indem sie beabsichtigte Verwendungen und Reaktionen des Testobjekts deutlich aufzeigen.

Kent Beck, der Vater von XP, schlug (damals noch für Smalltalk) ein kleines Framework vor, das das Erstellen solcher automatisierten Tests unterstützt. Mittlerweile kann dieses SUnit-Framework als der Vater einer ganzen Familie von Testframeworks für unterschiedliche Programmiersprachen angesehen werden. Den Vertreter dieser Familie für Java stellt das JUnit-Framework dar, an dessen Entwicklung neben Kent Beck auch Erich Gamma beteiligt war.

Das folgende Beispiel zeigt einen einfachen Test. Es soll überprüft werden, dass die Vergleichsoperation für eine Euro-Klasse korrekt implementiert ist. Der Test könnte dann folgendermaßen aussehen:

Verhält sich das Euro-Objekt wie erwartet, bestätigt JUnit dies durch einen grünen Balken:

Ein vom Test abweichendes Verhalten quittiert JUnit mit einem roten Balken:

Möchten Sie einen umfangreicheren Eindruck vom Testen erhalten? Dann schauen Sie sich einfach dieses Video an, in dem Ihnen gezeigt wird, wie testgetriebene Entwicklung in der Praxis aussehen kann.

In schwergewichtigen Methoden gibt es häufig ein eigenes Team, welches für die Qualitätssicherung zuständig ist und den Code des Entwicklunsteams testet. In agilen Vorgehensweisen ist eine solche Trennung nicht vorgesehen: Insbesondere im Rahmen testgetriebener Entwicklung werden  Unit-Tests immer von denselben Entwicklern geschrieben, die auch die zu testende Komponente entwickeln.

Gute Tests...

• ... sind isoliert: Sie sind voneinander unabhängig, so dass die Reihenfolge ihrer Ausführung das Testergebnis nicht beeinflusst. Schlägt ein Test fehl, so führt dies nicht dazu, dass weitere Tests fehlschlagen.
• ... sichern jeweils genau eine Eigenschaft ab. Ein Problem äußert sich immer in genau einem fehlschlagenden Test.
• ... sind vollständig automatisiert, damit sie auch bei erhöhtem Projektdruck noch häufig ausgeführt werden.
• ... sind leicht verständlich und kurz.
• ... weisen eine genau so hohe Codequalität auf, wie der Produktivcode selbst (Redundanzen, Code Conventions,…)
• ... testen relevanten Code (und z.B. keine Getter/Setter).
• ... sind um eine Testfixture gruppiert, nicht um eine Klasse.
• ... werden vor dem zu testenden Code geschrieben (siehe testgetriebeneEntwicklung )

Natürlich gibt es zahlreiche weitere Kriterien für gute Tests. Diese finden Sie in der Literatur, die am Ende dieser Seite aufgeführt ist.

Unsere Entwickler und Berater verfügen über jahrelange Erfahrung mit verschiedenen agilen Themen und Techniken. Da Komponententests für viele agile Themen eine wichtige Voraussetzung sind, ist das Testen mit JUnit in vielen unserer Schulungen als wichtiger Bestandteil enthalten:

• Inkrementeller Entwurf / Flexible Architekturen
• Automatisierter Build-Prozess
• eXtreme Programming
• TDD-Camp

Darüber hinaus bieten wir Unterstützung durch testerfahrenen agile Entwickler (mehr) und helfen Ihren eigenen Entwicklern dabei, Tests Gewinn bringender einzusetzen (mehr).

JUnit und verwandte Themen im Netz:

• JUnit
• Easy Mock
• Mocks Aren't Stubs
• Testgetriebene Entwicklung (TDD) 

Literaturempfehlungen:

• Frank Westphal: Testgetriebene Entwicklung mit JUnit & FIT. Sehr praxisnahe Einführung in die testgetriebene Entwicklung mit JUnit anhand eines durchgängigen Beispiels. Behandelt unter Anderem auch den Einsatz von Mocks sowie das Erstellen von Akzeptanztests mit Fit. Das Buch ist tutorialartig aufgebaut und eignet sich somit eher zum Durcharbeiten von "Deckel zu Deckel" denn als Nachschlagewerk.
• Johannes Link: Softwaretests mit JUnit. Das Buch behandelt die wichtigen Testtechnologien und ist ansonsten stark an gängigen Problemstellungen des Testens orientiert (z.B. Testen an der Datenbankschnittstelle, Testen asynchroner Dienste, Testen von Webanwendungen,...). Das Buch enthält weniger Tutorials und eignet sich daher auch gut als Nachschlagewerk.
• Kent Beck: Test-Driven Development By Example. Der Klassiker vom Erfinder der xUnit-Frameworks
• Gerard Meszaros: xUnit Test Patterns - Refactoring Test Code. Nichts für den absoluten Einsteiger in die Testmaterie, später aber (auch als Nachschlagewerk) sehr lohnend. Lassen Sie sich durch den Umfang nicht abschrecken!