JUnit ist ein Unit-Testing-Framework für die Programmiersprache Java. JUnit spielt eine wichtige Rolle bei der Entwicklung der testgesteuerten Entwicklung und gehört zu der Familie von Unit-Test-Frameworks, die zusammen als xUnit bekannt sind und ihren Ursprung in SUnit haben.
JUnit wird zur Kompilierzeit als JAR gelinkt. Bei einem JAR handelt es sich um ein Java Archiv (umgangssprachlich wegen der Dateiendung auch JAR-Datei genannt) dient der Gliederung, Verteilung und Bereitstellung von Klassenbibliotheken und ausführbaren Programmen, die in der Programmiersprache Java erstellt wurden. Technisch ist es eine komprimierte Datei im ZIP-Format. Das Archiv enthält kompilierte Java-Klassen (Bytecode) und ggf. weitere Ressourcen. In der Regel umfasst es auch eine oder mehrere Dateien mit Metadaten. Diese haben fest vorgegebene Namen und Strukturen und liegen im Verzeichnis META-INF. Wie es genau funktioniert, schreibe ich in einem zukünftigen Beitrag. Auf jeden Fall kann man sich die Kurzbezeichnung des Archivs als Wortspiel mit dem englischen Wort jar (deutsch: „Gefäß“) ganz gut merken.
Die neueste Version des Frameworks, JUnit 5, befindet sich im Paket org.junit.jupiter. Die Vorgängerversionen JUnit 4 und JUnit 3 waren unter den Paketen org.junit bzw. junit.framework zu finden.
Eine im Jahr 2013 durchgeführte Umfrage unter 10.000 auf GitHub gehosteten Java-Projekten ergab, dass JUnit (gleichauf mit slf4j-api) die am häufigsten eingebundene externe Bibliothek ist. Jede Bibliothek wurde von 30,7 % der Projekte verwendet.
Wie funktioniert JUnit?
Ein JUnit-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt (dann ist dieser „grün“) oder er misslingt (dann ist dieser „rot“). Das Misslingen kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben. Beides signalisiert via Exception (Eine Ausnahmesituation, normalerweise durch Fehler hervorgerufen). Der Unterschied zwischen den beiden Begriffen liegt darin, dass man Failures erwartet, während Errors eher unerwartet auftreten.
Technisch betrachtet, sind Failures mittels einer speziellen Exception namens AssertionFailedError gekennzeichnet. Die Interpretation aller übrigen Exceptions erfolgen vom JUnit-Framework durch Errors.
JUnit im Softwareentwicklungsprozess
JUnit ist ein wichtiges Hilfsmittel im Extreme Programming und unterstützt in diesem Zusammenhang die Idee des Extreme Testing. Als Programmierer schreibt man zuerst einen automatisch wiederholbaren (JUnit-)Test und dann den zu testenden Code.
Der Test selbst ist ebenfalls ein Stück Software und ebenso wie der zu testende Code ist dafür die Programmierung notwendig.
Wenn man zu einem späteren Zeitpunkt den Code eines anderen Programmierers zum Ändern beabsichtigt, so ruft man zuerst alle JUnit-Tests auf, um sich zu vergewissern, dass der Code vor der Änderung fehlerfrei ist. Dann führt man die Änderung durch und ruft die JUnit-Tests erneut auf. Misslingen diese, so hat man die Erkenntnis, dass man selbst Fehler gemacht hat und muss diese korrigieren. Dieser Zyklus wiederholt sich so lange, bis alle JUnit-Tests wieder fehlerfrei durchlaufen.
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 man nichts implementiert, was man nicht auch testet. Entstehen Testfälle erst nach der Entwicklung des Codes, so ist die Wahrscheinlichkeit höher, wichtige Testfälle zu übersehen. Doch darüber habe ich bereits hier einen Artikel geschrieben.
Plugins und Erweiterungen für JUnit
Eine Implementierung von JUnit für Jakarta EE ist Cactus (ehemals J2EEUnit) aus dem Jakarta-Projekt. Seit Java EE 5 haben sich sogenannte Out-of-container-Frameworks (zum Beispiel EJB3Unit) etabliert, die eine Ausführung von Tests außerhalb eines Containers erlauben.
Erweiterungen für JUnit dienen in der Regel für den Einsatz in spezifischen Bereichen (beispielsweise httpsUnit für Webentwicklung, DBUnit für Datenbankentwicklung). Darüber hinaus gibt es noch Plugins für Entwicklungsumgebungen, die den Einsatz innerhalb der Entwicklungsumgebung ermöglichen beziehungsweise erweitern (beispielsweise Infinitest für kontinuierliches Testen oder DJUnit für Berechnung der Code-Abdeckung, englisch Code Coverage, der Tests).
Testabdeckung
Bei der Testabdeckung geht es um das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen bzw. der Menge der gewünschten treffbaren Aussagen. Die Testabdeckung spielt als Metrik zur Qualitätssicherung und zur Steigerung der Qualität insbesondere im Maschinenbau und der Softwaretechnik eine große Rolle.
Die Testabdeckung lässt sich durch eine Erhöhung der Zahl an Messungen, Stichproben und Testfällen verbessern. Begrenzt wird die Testabdeckung in der Praxis jedoch durch die Kosten, die mit jedem Test verbunden sind. Doch dies ist ein komplexes Thema, welches ich gerne in einem separaten Beitrag thematisiere.
Fazit
JUnit ist ein einfach zu benutzendes und leichtgewichtiges Framework für die Entwicklung von Softwaretests. Eine Integration in verschiedene IDE’s ist möglich. Dies thematisiere ich aber in den Artikeln zu den einzelnen IDE’s. Diese verlinke ich dann selbstverständlich auch hier. Die Ausführung einzelner Tests oder kompletter Testsuiten ist im Entwicklungsprozess jederzeit möglich. Nur das Programmieren der Tests kann man damit naturgemäß nicht leisten. Jedoch ist die Einstiegshürde für einen relativ guten Entwickler minimal. Es ist dabei sehr zu empfehlen, möglichst frühzeitig mit der Erstellung von Tests zu beginnen! In der Literatur beginnt die Erstellung der Tests, besonders im agilen Umfeld. Zeitgleich mit der Entwicklung selbst. Sie sind der wichtigste Bestandteil der Qualitätssicherung. Insbesondere spätere Änderungen an der Software im Rahmen funktionaler Erweiterungen oder eines Refactorings sind ohne vorhandene Regressionstests oftmals gar nicht durchführbar.