Vergleich JUnit 3.8 mit JUnit 4.4
http://www.junit.org
Download from Sourceforge
Beide Versionen stehen unter der Common Public Licence (CPL)
Verglichen werden die Versionen JUnit 3.8 und JUnit 4.4.
13.05.2008
JUnit 3.8/ 4.4 wurde zum Testen von Java-Programmen entwickelt, mit dem Tool lassen sich automatisierte Unit-Tests einzelner Klassen, Methoden oder Testsuiten durchführen. JUnit entscheidet bei seinen Tests in zwei Ergebnisse, Test durchlaufen mit Ok (grün), Test abgebrochen (rot). Kenntnisse von JUnit3.x können hilfreich sein, da weitere Testwerkzeuge auf dieser JUnit-Version basieren und gegebenenfalls nicht aktualisiert werden, damit auch Java 1.4.x-Code testbar bleibt.
Auf den ersten Blick fallen die Änderungen der Versionen nicht sofort ins Auge, schaut man jedoch etwas genauer hin, werden die neuen Features sichtbar und erweisen sich als sehr nützlich und hilfreich. JUnit bietet, egal in welcher Version, eine sehr gute Möglichkeit, Java-Programme zu testen. Das Werkzeug ist sehr mächtig und stellt umfangreiche Test- und Automatisierungsszenarien zur Verfügung. Die neue Version von JUnit 4.x nutzt erstmals Annotationen, die das Schreiben von Testfällen erleichtern, da Methodennamen frei und beliebig vergeben werden können. Zusätzlich wurden neue Testmethoden hinzugefügt, die das Testen von Programmen weiterhin erleichtern sollen. JUnit Fehlermeldungen wurden dahingehend verbessert, dass die Möglichkeit besteht, eigene Fehlermeldungen zu schreiben. Jedoch stellt sich die Frage, ob man die Funktion wirklich braucht, da die Fehlermeldungen von JUnit sprechend und sehr gut sind.
Allgemein gilt für beide Versionen:
Für unerfahrene Nutzer ist es am Anfang eher schwierig, sich in die Testmechanismen einzuarbeiten. Da JUnit sehr verbreitet und oft genutzt wird, findet man gute und hilfreiche Literatur im Internet die das Einarbeiten sehr erleichtern.
Die Einsatzgebiete beider Versionen sind gleich gebliebenen, da die Version 3.8 lediglich verbessert wurde auf die Version 4.4.
JUnit wird im Java Umfeld von Entwicklern genutzt, die das Innenleben einer Klasse kennen, um Unit-, Komponenten- und White-Box-Tests zu schreiben.
Plugin für Eclipse oder als Standalone Anwendung
Zur Installation von JUnit muss das heruntergeladene Zip-File in einem beliebigen Ordner entpackt werden. In diesem Ordner befindet sich eine JAR-Datei (junit-4.4.jar), diese Datei muss in die Pfadvariable des Systems integriert werden.
- Linux: In einer Shell 'export PATH=$PATH:/verzeichnis/zum/junit4.4/junit-4.4.jar' eingeben. ACHTUNG: der Pfad wird nur für die aktuelle Sitzung gesetzt.
- Permanente Nutzung durch Einfügen in die Datei '/home/user/.bashrc', 'export PATH=$PATH:/verzeichnis/zum/junit4.4/junit-4.4.jar'
- Windows: set classpath=%classpath%;INSTALL_DIR\junit-4.4.jar;INSTALL_DIR
- Alternativ kann auf beiden Systemen die JAR-Datei in den Classpath von Eclipse eingebunden werden.
Diese Schritte reichen aus, um JUnit auf einem System zu installieren. Um die Installation zu testen kann folgender Befehl in einer Konsole eingegeben werden [java org.junit.runner.JUnitCore org.junit.tests.AllTests]. Mit diesem Aufruf werden mitgelieferte JUnittests ausgeführt um zu zeigen, dass JUnit korrekt installiert wurde. Diese Tests sollten alle korrekt durchlaufen. Zusätzlich besteht die Möglichkeit, JUnit in Eclipse zu verwenden, wie JUnit in Eclipse genutzt werden kann, wird im nächsten Abschnitt beschrieben.
Einbinden in Eclipse:
Ein neues Java-Projekt erstellen oder ein schon Bestehendes öffnen bzw. auswählen. Auf Project --> Properties klicken, Java Build Path, Libraries auswählen, und auf Add External JARs klicken. Jetzt zu junit-4.4.jar navigieren und auswählen. Okay drücken. Anschließend kann eine neue JUnit-Testklasse erstellt werden.
Im Ordner von JUnit befinden sich zwei weitere Ordner, die als Dokumentation von JUnit genutzt werden können. Im Ordner javadoc befindet sich die generierte Dokumentation aus den Quelldateien, die Hinweise über einzelne Klassen, Objekte und Methoden gibt. Im Ordner doc befinden sich weitere Ordner, die eine entsprechende Doku enthalten über FAQ, Cookbook und über den Aufbau von Tests. Weitere Informationen, Hinweise und Tipps befinden sich auf der Webseite von JUnit. Bei den Dokumentationen wurden für JUnit 4.4 lediglich die Neuerungen und Unterschiede in die entsprechenden Dateien eingebaut.
Die Projektseite von JUnit ist sehr gut strukturiert und besitzt einen übersichtlichen Aufbau. Die Seite gewährt einen schnellen Einblick in die Funktionalität von JUnit. Die Webseite wird stetig weiterentwickelt und mit neuem Inhalt aktualisiert.
Registrierung auf der Webseite ist möglich. Eine Mailinglist mit den Entwicklern ist auf der Seite integriert, mit Statusanzeige wer gerade Online ist. Es besteht die Möglichkeit, einen beliebigen Entwickler direkt per E-Mail zu kontaktieren.
Die Nutzbarkeit von JUnit ist sehr gut. Um einen neuen Unit-Test anzulegen, wird eine JUnit Testclass ausgewählt. Hat man seinen Test geschrieben und lässt ihn laufen, wird in Eclipse ein JUnitfenster geöffnet in dem die Ergebnisse des Tests aufgelistet werden.
Automatisierung über sogenannte Testsuiten die flexibel Mengen von Tests zusammenfassen könne. Eine Testzusammenfassung mit Hilfe von XML möglich.
Als einführendes Beispiel werden verschiedene If-Bedingungen und Zahlenberechnungen getestet (Fakultät und Fibonacci Zahlen).
Beim Anlegen der Testklassen in Eclipse hat sich von der Version 3.8 zu 4.4 nichts geändert. Der Aufbau der Testklassen hat sich hingegen verändert. Die Änderungen werden im letzten Abschnitt beschrieben.
JUnit3.8 Klassen:
JUnit4.4 Klassen:
Anlegen einer neuen JUnit Klasse.
Nachdem die Tests geschrieben wurden, klickt man z.B. rechts auf die Testklasse und wählt Run As --> JUnit Test Case aus.
Wenn der Test durchgelaufen ist, wird folgende Ansicht in Eclipse sichtbar und zeigt, ob der Test korrekt durchlaufen wurde oder nicht.
Siehe Hilfe von JUnit, FAQ und Cookbook.
Unterschiede im Überblick
Mit den Neuentwicklungen von JUnit 4.x wurde die Java Version 1.5 verwendet. JUnit4.x baut im Gegensatz zu JUnit 3.81 auf Annotationen auf, die ein neues Ausdrucksmittel in der Metaprogrammierung darstellen. In Java bzw. JUnit4.x werden die Annotationen durch ein @ eingeleitet und dienen als Hilfsmittel, den Code mit frei wählbaren Anmerkungen zu versehen. JUnit4.x verwendet Annotationen, um Testfälle als solche zu markieren, dazu wird vor die Methode @Test geschrieben. In JUnit 3.8x müssen alle Methoden, die etwas mit einem Test zu tun haben mit testXXXXX() beginnen, damit sie in einen Test mit einbezogen werden.
import junit.framework.TestCase;
import org.junit.Test;
import static org.junit.Assert.*;
public class IntegrationsTest extends TestCase{
@Test
public void testWahrFalsch1(){
...
}
In obigen Beispiel kann man sehr schön erkennen, was sich zwischen den beiden Versionen grundsätzlich geändert hat. Die durchgestrichenen Programmteile waren für JUnit 3.8x notwendig, der fettgedruckte Programmcode ist nun für JUnit4.x. Mit der neuen Version von JUnit4.x kommt ein neuer Namensraum [org.junit.*] zum Einsatz, dieser enthält den annotationsbasierten Code. Das Paket [junit.framework] bleibt in der neuen Version bestehen, es wurden lediglich kleine Änderungen vorgenommen, um die Aufwärtskompatibilität zu sichern.
Zusätzlich wurde eine neue assert-Methode hinzugefügt, sie trägt den Namen assertThat und bekommt zwei Parameter übergeben. Der erste Parameter ist der tatsächliche Wert (im Gegensatz zu assertEquals als ersten Parameter) und einen sogenannten Matcher. Mit dem Matcher wird die zu testende Bedingung ausgedrückt.
Aus assertEquals(10, list.size());
wird
assertThat(list.size(), is(10));
Um die neue Funktion zu nutzen, müssen die Hamcrest-Pakete eingebunden sein:
import static org.hamcrest.core.Is.is;
Mit JUnit4.x wurden sechs unterschiedliche Annotationen eingeführt:
- @Test kennzeichnet die Methoden als Testfälle.
- @Before und @After markieren Setup- bzw. Teardown-Methoden, die für jeden Testfall wiederholt werden.
- @BeforeClass und @AfterClass markieren Setup- bzw. Teardown-Methoden, die nur einmal pro Testklasse wiederholt werden.
- @Ignore kennzeichnet Testfälle, die bei einem Testlauf nicht beachtet werden sollen.
Zur Literatur
Zurück zur Werkzeugübersicht
Zurück zur CSI-Hauptseite