Unit Testing in Java Teil 3: JUnit’s Testmethoden
Letzte Woche haben wir ein einfaches Beispiel zur Demonstration von JUnit erstellt. Heute wollen wir uns die Testmethoden anschauen, welche JUnit schon von Haus aus mitbringt. Diese Methoden werden Assertions benannt, vielleicht dem einen oder anderen ein schon bekannter Ausdruck von anderen Programmiersprachen. Im Englischen bedeutet das Wort to assert soviel wie behaupten, feststellen oder versichern. Wir stellen also fest, das eine gewisse Bedingung eintrifft.
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.
