Alle Assertions in JUnit beginnen mit dem Schlüsselwort assert, folgende stehen uns dabei zu Verfügung:

• assertEquals
• assertNull
• assertSame
• assertTrue
• assertArrayEquals

Analog zu diesen Funktionen gibt es auch die entsprechenden negierenden Funktionen

• assertNotNull
• assertNotSame
• assertFalse

Die einzelnen Funktionen befinden sich alle in der Klasse Assert im Paket junit.framework. Neuere Funktionen befinden sich in org.junit. Die JavaDoc zu Junit kann man auf der offiziellen Website von JUnit finden.

static void assertEquals([String message], expected, actual)

assertEquals wird am Häufigsten verwendet. Die Funktion überprüft ob der Erwartungswert expected dem tatsächlichen Wert actual entspricht. Der Test schlägt fehl, wenn sich die beiden Werte gleichen. Möchte man eine eigene Nachricht definieren, welche bei Fehlschlagen des Tests angezeigt wird, so kann man das über den optionalen Parameter message angeben. Die Parameter expected und actual können beliebige Datentypen aufnehmen, von primitiven Datentypen wie int oder boolean bis zu allen Objekten die in Java erstellt werden. Werden Arrays miteinander verglichen wird nicht der Inhalt der Arrays, sondern lediglich die Referenz auf die Arrays zum Vergleich verwendet.

static void assertEquals([String message], expected, actual, tolerance)

Eine Besonderheit stellt der Vergleich von Fließkommazahlen dar, da mit ihnen nicht immer exakte Werte verglichen werden können. Das wird hauptsächlich durch die begrenzte Anzahl von Dezimalstellen nach dem Komma und den nach sich ziehenden Rundungs- und Berechnungsfehlern verursacht. Zum Ausgleich bietet asserEquals den Wert tolerance an, welcher die Genauigkeit nach dem Komma angibt. Gibt man für tolerance zum Beispiel den Wert 0.001 an, dann werden nur die letzten 3 Stellen nach dem Komma berücksichtigt. 0.01 wären 2 Stellen 0.000001 wären 6 Stellen.

static void asserNull([String message], java.lang.Object object)

assertNull überprüft ob ein Objekt null ist. Wie auch bei den anderen Assertions kann eine benutzerdefinierte Nachricht über den optionalen Parameter message angegeben werden. Analog dazu gibt es die Methode assertNotNull, welche überprüft ob das übergebene Objekt nicht null ist.

static void assertSame([String message], expected, actual)

Diese Methode überprüft ob zwei Objeke gleich sind. Dabei wird nicht überprüft ob die Inhalte, sondern ob die Objekttypen übereinstimmen. Wie auch bei assertNull das Gegenteil mit assertNotNull getestet werden kann, gibt es für diese Funktion den Gegenspieler asserNotSame.

static void assertTrue([String message], boolean condition)

Hier wird geprüft ob die Bedingung condition true ergibt. Das kann ein arithmetischer Ausdruck sein, aber auch ein Funktionsaufruf. Der Gegenspieler hierzu ist assertFalse, welcher (Überraschung) überprüft ob die angegebene Bedingung false ergibt. message ist, wie bei den vorherigen Funktionen, wieder der optionale Parameter mit welchem man eine benutzerdefinierte Nachricht angeben kann.

static void assertArrayEquals([String message], expecteds, actuals)

Wie schon erwähnt ist es nicht möglich die Inhalte von Arrays über die Funktion assertEquals zu vergleichen. Dafür gibt es die Funktion assertArrayEquals. Diese funktioniert genau gleich wie assertEquals, vergleicht jedoch die einzelnen Inhalte der Arrays. Diese Funktion steht erst ab Version 4.3 der JUnit API zur Verfügung.

static void fail([String message])

Eigentlich ist diese Funktion nicht wirklich eine Assertion, da keine Werte getestet werden. Der Test schlägt mit dieser Methode automatisch fehl und wird häufig dazu verwendet um Zweige des Programms zu testen, welche eigentlich nie erreicht werden dürften.

Mit diesen Funktionen als Handwerkszeug sind die meisten Testfälle abgedeckt. Im nächsten Teil der Serie werden wir Best Practices und wie getestet werden sollte besprechen.

Schritt 1: Erstellen eines JUnit-Projekts in Eclipse

Abbildung 1: Neues Projekt erstellen

Abbildung 2: Build Einstellungen

Abbildung 3: Auswahl der Bibliothek

Abbildung 4: JUnit-Version

Erstellen Sie ein neues Java-Projekt in Eclipse und vergeben Sie einen sinnvollen Namen (Abbildung 1). Unser Beispiel wird aus simplen Rechenfunktionen bestehen. Wichtig ist, das in den Build-Einstellungen im Reiter Libraries die JUnit-Bibliothek eingebunden wird. Dazu wählt man Add Library … (Abbildung 2) und dann JUnit (Abbildung 3). Im darauffolgenden Fenster kann die Version von JUnit ausgewählt werden. In unserem Fall nehmen wir die Version 4 (siehe Abbildung 4).

Schritt 2: Anlegen eines Tests

Abbildung 5: JUnit in Eclipse

Wir legen uns die Klasse Rechnen.java (Quellcode 1) in unserem Projekt an. Das wird die Klasse sein, welche die zu testenden Funktionen enthält. Wir erstellen uns eine Methode names addiere(). Die Funktion empfängt zwei Zahlen addiert diese beiden und gibt diese zurück. Wir werden diese Klasse später noch um weitere Funktionen erweitern. Wie ich in Teil 1 der Artikelreihe schon erwähnt habe, werden für gewöhnlich die Tests zuerst geschrieben und dann die Funktion implementiert.

Als nächstes erstellen wir uns die Klasse TestRechnen.java (Quellcode 2). Diese erbt von der JUnit-Klasse TestCase. Wir erzeugen eine neue Instanz von Rechnen, deren Funktionen wir Testen wollen. Die Methode, welche den Test ausführt nennen wir testAddiere(). Alle Methoden, welche einen Test ausführen, müssen auch mit test beginnen. Innerhalb der Funktion wird assertEquals aufgerufen. Diese Funktion wird von JUnit gestellt. AssertEquals überprüft ob der Wert den man erwartet der Gleiche ist, welcher von der zu testenden Funktion zurückgegeben wird. In unserem Beispiel erwarten wir das der Aufruf der Methode addiere mit den Zahlen 1 und 1, 2 ergeben.

Quellcode 1: Rechnen.java
package de.zeroseven.tutorials;

public class Rechnen {

	public int addiere(int zahl1, int zahl2) {
		return zahl1 + zahl2;
	}
}

Um unseren Test nun auszuführen, klicken wir mit Rechts auf TestRechnen und wählen Run As … -> JUnit-Test. In dem sich darauf öffnenden (Abbildung 5) Fenster, werden nun alle Tests angezeigt. Die allerwichtigste Anzeige ist der große grüne Balken, welcher anzeigt das alle Tests ohne Fehler durchlaufen worden sind. 1 und 1 sollte ja auch 2 ergeben. Um zu sehen, wie es aussieht wenn ein Test schief läuft, stellen Sie den Erwartungswert auf was Anderes als 2. Dann wird der grüne Balken rot angezeigt.

Quellcode 2: TestRechnen.java
package de.zeroseven.tutorials;

import junit.framework.TestCase;

public class TestRechnen extends TestCase {

	private Rechnen myRechnen = new Rechnen();

	public void testAddiere() throws Exception {
		assertEquals(2, myRechnen.addiere(1,1));
	}
}

Unterhalb des Balkens werden Details zum Schieflaufen des Tests angezeigt, wie zum Beispiel wo der Fehler aufgetreten ist. Was uns durch die Veränderung des Erwartungswertes angezeigt wird ist kein Fehler sondern ein Failure. Ein Fehler wird in JUnit als Error bezeichnet. Um dies zu provozieren fügen wir eine neue Testfunktion namens testError ein (Quellcode 3). Diese macht nichts anderes als eine Exception zu werfen. Ändern Sie den Erwartungswert wieder auf 2 und starten sie den Unit-Test neu. Nun wird ein Fehler und kein Failure mehr angezeigt.

Quellcode 3: Funktion die einen Error erzeugt
public void testError() throws Exception {
	throw new Exception("Irgendwas lief schief");
}

Das war unser erster einfacher Unit-Test. Im nächsten Teil der Reihe werde ich auf die unterschiedlichen Testmethoden wie assertEquals, welche JUnit schon mitbringt.

Ein Unit-Test beschreibt einen Test der den logischen Teil einer Software testet, der nicht syntaktisch oder aufgrund implementierter Fehlererkennung zu Fehlern führen kann. Ein Beispiel ist ein Algorithmus der 2 Zahlen addiert. Ein Unit-Test kann nun zum Beispiel überprüfen, ob richtig addiert wird, indem man dem Test Eingabeparameter und das zu erwartende Ergebnis mitgibt. Stimmt das errechnete Ergebnis nun mit dem zu erwartenden Ergebnis überein, so wird der Test erfolgreich durchlaufen. So können automatsich Zustände abgefangen werden, die häufige Fehlerquellen sind. Zum Beispiel die Eingabe von negativen Werten, Duplikaten oder null. Das Ergebniss kann entweder ein OK, ein Failure oder ein Error sein. Failures treten am häufigsten auf und beschreiben das “Fehlschlagen” des Tests. Dabei werden die Erwartungswerte des Tests nicht erfüllt. Ein Error tritt auf wenn ein Fehler auftritt, der ein “richtiger Softwarefehler” ist. So werden nach und nach alle Komponenten getestet. Ziel sollte es sein, das keine Funktion und Klasse als Produktionscode gesehen werden soll, bis nicht alle Tests erfolgreich durchlaufen werden.

Unit-Testing beeinflusst durch seine Modularität den gesamten Entwicklungsprozess. Fügt ein Entwickler weitere Änderungen zum Code hinzu, dann prüft er zuerst ob die Software alle Tests erfolgreich durchläuft und stellt somit sicher das später auftretende Fehler höchstwahrscheinlich an seiner Implementierung liegen.

Ich verwende in diesen Artikeln Eclipse das JUnit schon mit sich führt. Arbeitet man ohne Eclipse müssen die entsprechenden Klassenpfade und Bibliotheken angepasst werden. Auf www.junit.org kann man sich die aktuelle Version herunterladen und weitere Informationen zu JUnit erhalten.

In Teil 2 dieses Artikels werden wir nächste Woche unseren ersten Unit-Test schreiben und anwenden.