JUnit

JUnit
Entwickler	u.a. Kent Beck und Erich Gamma
Aktuelle Version	4.10 (5. Oktober 2011)
Betriebssystem	Plattformübergreifend
Programmier­sprache	Java
Kategorie	Test-Framework
Lizenz	Common Public License
Deutschsprachig	nein
www.junit.org

JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units (meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die ursprünglich unter dem Namen SUnit für Smalltalk entwickelt wurden.

Mittlerweile existieren JUnit-ähnliche Frameworks auch für viele andere Programmiersprachen. Oft werden diese Programme unter dem Namen xUnit zusammengefasst.

Funktionsweise

Ein JUnit-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt (dann ist er „grün“) oder er misslingt (dann ist er „rot“). Das Misslingen kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben, die beide per Exception signalisiert werden. Der Unterschied zwischen den beiden Begriffen liegt darin, dass Failures erwartet werden, während Errors eher unerwartet auftreten. Technisch werden Failures mittels einer speziellen Exception namens „AssertionFailedError“ signalisiert, während alle übrigen Exceptions vom JUnit-Framework als Error interpretiert werden.^[1]

Hauptentwickler des JUnit-Frameworks sind Erich Gamma und Kent Beck.

JUnit im Softwareentwicklungsprozess

JUnit ist ein wichtiges Hilfsmittel im Extreme Programming und unterstützt in diesem Zusammenhang die Idee des Extreme Testing.

Vorgehensweise

Dabei schreibt ein Programmierer zuerst einen automatisch wiederholbaren (JUnit-)Test und dann den zu testenden Code. Der Test ist selbst ein Stück Software und wird ebenso wie der zu testende Code programmiert. Wenn zu einem späteren Zeitpunkt ein anderer Programmierer den so entstandenen Code ändern möchte, so ruft er zuerst alle JUnit-Tests auf, um sich zu vergewissern, dass der Code vor seiner Änderung fehlerfrei ist. Dann führt er die Änderung durch und ruft die JUnit-Tests erneut auf. Misslingen diese, so weiß er, dass er selbst einen Fehler eingebaut hat und muss ihn korrigieren. Dieser Zyklus wiederholt sich solange, bis alle JUnit-Tests wieder „grün“ sind.

Dieses Verfahren wird auch „Testgetriebene Entwicklung“ (englisch test-driven software development) genannt und zählt zu den agilen Methoden. Die Idee dabei ist fehlerarmen Code zu erzeugen, indem nichts implementiert wird, das nicht auch getestet wird. Werden Testfälle erst nach dem Code entwickelt, so ist die Wahrscheinlichkeit höher, wichtige Testfälle zu übersehen.

Kritik

Der beschriebene methodische Einsatz von JUnit (oder auch anderen ähnlichen Hilfsmitteln) kann (wie jeder Test) die Fehlerfreiheit des erzeugten Codes nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen des Verfahrens liegen notwendigerweise darin, dass nur solche Fehler gefunden werden können, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nicht unbedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, könnte dazu führen, dass tatsächlich (unbewusst) nur soviel getestet wird, dass alle Tests „grün“ sind; Code als fehlerfrei zu behandeln, der „grün“ testet, ist ein häufiges Anti-Pattern in der Praxis testgetriebener Entwicklung, das nur durch Disziplin und hinreichenden gedanklichen Abstand beherrscht werden kann.

Die oben beschriebene Vorgehensweise bei der Änderung von Code stellt lediglich sicher, dass keine solchen Fehler unbemerkt eingefügt werden, die der vorhandene Bestand an Tests sicher aufdeckt. Das Problem, eine ausreichende Testabdeckung herzustellen, kann nur durch entsprechende Beachtung und geeignete Maßnahmen gelöst werden.

Ein weiteres Problem ergibt sich, wenn der Autor von Tests für den Code mit dem Autor des Codes identisch ist. Dies widerspricht dem Prinzip, dass Entwickler und Tester nicht dieselbe Person sein sollten, und könnte u.a. die Wahrscheinlichkeit erhöhen, dass Denkfehler in der Implementierung auch im Test erscheinen und nicht aufgedeckt werden. Wenn es sich um dieselbe Person handelt, wird dies auch nicht dadurch ausgeschlossen, dass die Tests zuerst entwickelt werden, da sowohl die beabsichtigte Funktionsweise des Codes, als auch seine zukünftige Gestalt bereits im Denken des Testautors und späteren Codeautors präsent sein können.

JUnit-Erweiterungen

Eine Implementierung von JUnit für Java EE ist Cactus (ehemals J2EEUnit) aus dem Jakarta-Projekt. Seit JEE 5 haben sich so genannte Out-of-container-Frameworks (zum Beispiel EJB3Unit) etabliert, die eine Ausführung von Tests außerhalb des Containers erlauben.

Erweiterungen zu JUnit erweitern JUnit für den Einsatz in bestimmten Bereichen (beispielsweise HTTPUnit für Webentwicklung, DBUnit für Datenbankentwicklung). Darüber hinaus gibt es noch Plugins für Entwicklungsumgebungen, die den Einsatz von JUnit innerhalb der Entwicklungsumgebung ermöglichen beziehungsweise erweitern (beispielsweise Infinitest für kontinuierliches Testen oder DJUnit für Berechnung der Code Coverage der Tests).

Versionsgeschichte

JUnit 4.8 

Diese Version unterstützt Kategorien. Tests können mit Kategorien markiert werden. Dadurch ist es möglich, nur Tests einer bestimmten Kategorie auszuführen.^[2]

Siehe auch

• TestNG – Alternative zu JUnit
• Apache Cactus, HTTPUnit, DBUnit – bekannte Erweiterungen zu JUnit
• EasyMock, Mockito, PowerMock - JUnit-basierte Mocking-Frameworks

Literatur

• Johannes Link: Softwaretests mit JUnit – Techniken der testgetriebenen Entwicklung. ISBN 3898643255
• Frank Westphal: Testgetriebene Entwicklung mit JUnit und FIT. ISBN 3898642208
• Klaus Meffert: JUnit Profi-Tipps – Software erfolgreich testen. ISBN 3935042760

Weblinks

• JUnit Homepage (Englisch)
• JUnit-4.0-Neuerungen
• Entwurfsmuster mit JUnit testen (Singleton, Iterator)
• JUnit Cookbook – eine kurze Anleitung zum Arbeiten mit JUnit (Englisch)
• JUnit Präsentation (Englisch)

Einzelnachweise

1. ↑ Mike Clark, Consulting: JUnit FAQ. What's the difference between a failure and an error?. 28. Dezember 2004, archiviert vom Original am 30. Dezember 2004, abgerufen am 25. Oktober 2010 (englisch, Gilt für JUnit 3. Könnte sich geändert haben!): „Assertions are used to check for the possibility of failures, therefore failures are anticipated. Errors are unanticipated problems resulting in uncaught exceptions being propagated from a JUnit test method.“ 
2. ↑ Release Notes zu JUnit 4.8