Databases Reference
In-Depth Information
werden, wie z. B. die Herstellung einer Datenbankverbindung,
die dann in einer Klassenvariablen gespeichert wird.
Die Annotation @Before steht an Methoden, die vor jedem Test
ausgeführt werden sollen. Innerhalb dieser Methoden wird
dann die genaue Ausgangslage für alle Tests beschrieben. Ty-
pisch ist es, dass hier Exemplarvariablen der Testklasse einen
konkreten Wert erhalten, wie es im Beispiel mit der Variablen
wert der Fall ist. Im Fall einer Datenbank können bestimmte
Einträge in der Datenbank vorgenommen werden.
Mit den mit @After markierten Methoden kann nach jedem
Testfall und mit @AfterClass markierten Methoden nach der
Ausführung aller Tests aufgeräumt werden. Dies beinhaltet
später auch den Abbau der Datenbankverbindung.
Jeder Testfall ist mit @Test annotiert, der Methodenname be-
ginnt üblicherweise mit „test“ und wird im Namen durch eine
etwas genauere Beschreibung, was getestet werden soll, er-
gänzt. In Testmethoden werden die einzelnen Schritte des Tests
beschrieben, was einem normalen Java-Programm entspricht.
In jedem Test werden die erreichten Ergebnisse mit Zusiche-
rungen überprüft, wozu die Klasse Assert einige Klassenme-
thoden zur Verfügung stellt. Die wichtigste Methode assertTrue
wird in test1 vorgestellt, sie hat als Parameter einen Text und
einen Booleschen Ausdruck. Genauer wird getestet, dass der
Boolesche Ausdruck nach wahr ausgewertet wird. Ist dies nicht
der Fall, ist der Testfall gescheitert und wird von JUnit proto-
kolliert. Ein gescheiterter Test wird sofort beendet, weshalb
man viele kleine Tests statt lange Tests zur gleichzeitigen Über-
prüfung vieler Fehlermöglichkeiten schreiben sollte. In test1
und test2 wird korrekt angenommen, dass wert immer den
Ausgangswert 42 hat, test2 zeigt auch, dass man den ersten
String weglassen kann. Der String wird nur im Fehlerfall aus-
gegeben und kann so bei der Fehleranalyse sehr hilfreich sein.
Der Testfall test3 ist sehr ähnlich aufgebaut, zeigt aber die Mög-
lichkeit, auch einen falschen Testfall zu schreiben. Der korrekte
Wert müsste 45 sein, auf den wird aber nicht geprüft. Dies be-
deutet, dass man bei gescheiterten Testfällen immer darüber
nachdenken muss, ob es einen Fehler in der getesteten Software
gibt, oder ob der Testfall fehlerhaft ist.
Mit test4 wird gezeigt, dass man mit JUnit auch systematisch
Exceptions analysieren kann. Im konkreten Fall wird eine
ArithmeticException nach 42/0 erwartet. Die Programmzeile
Rahmenbedin-
gungen für ein-
zelne Tests
Zusicherungen
viele kurze Tests
Analyse von
Exceptions
308
