22.7 JUnit-Erweiterungen, Testzusätze
Das Framework JUnit selbst ist recht kompakt, doch wie an AssertJ abzulesen ist, gibt es die Notwendigkeit für komfortable Testmethoden, die häufig wiederkehrende typische Testaufgaben vereinfachen. Dazu zählen nicht nur Methoden, die testen, ob ein Element in einer Datenstruktur ist, sondern auch Unterstützungen für Tests mit Datenbankzugriffen, REST-Aufrufen oder GUI-Tests.
Webtests
Beim Testen von Webanwendungen kommen zwei Verfahren zum Einsatz. Das eine ist eine werkzeugunterstützte Aufzeichnung von Webinteraktionen und das automatische Abspielen der Folgen für den Test, und das andere ist die programmierte Lösung. Für die Aufzeichnung bietet sich das freie Selenium (http://seleniumhq.org) bzw. die Integration in Chrome und Firefox mit der Selenium IDE (http://seleniumhq.org/projects/ide) an. Wer Tests programmieren möchte, der findet mit Apache HttpUnit (http://httpunit.sourceforge.net) eine gute Basis.
Tests der Datenbankschnittstelle
Der Zugriff auf die Datenbank geschieht in der Regel über Repository-Klassen (auch DAO-Klassen genannt). Greift ein Service auf eine Datenbank zu, so geht er immer über das Repository. Der Test des Service wird dadurch vereinfacht, dass statt einer Datenbank-Repository-Implementierung ein Repository-Dummy untergeschoben wird. Bleibt die Frage, wie die Repository-Klassen zu testen sind.
Tests können sehr lange dauern, denn die Interaktion mit der Datenbank ist häufig der langsamste Schritt in einer ganzen Geschäftsanwendung. Eine Herangehensweise ist, die Tests lokal im Speicher laufen zu lassen. Dazu werden In-Memory-Datenbanken wie Derby, H2 oder HSQLDB verwendet. Die Datenbank liegt also komplett im Speicher, und so läuft ein Test sehr schnell. Die größten Nachteile dabei sind, dass es verschiedene SQL-Dialekte gibt und dass bisher keine In-Memory-Oracle-Datenbank existiert. Wenn die Repository-Implementierung für Massenoperationen auf eine gespeicherte Oracle-Prozedur zurückgreift, so kann die einfache Datenbank H2 das nicht testen.
Eine weitere Aufgabe ist das Füllen der Datenbank mit Testdaten. Die Open-Source-Software DbUnit (http://dbunit.sourceforge.net) ist hier eine große Hilfe. Externe Daten sind in XML verfasst und können leicht in die Datenbank importiert werden, bevor dann der Test auf diesen Probedaten arbeitet. Die Probedaten werden dann, wenn möglich, in der In-Memory-Datenbank eingefügt oder in einer lokalen Entwicklungsdatenbank. Für fortgeschrittene Tests (und insbesondere zum Abschätzen der Laufzeit) müssen Tests aber auch mit einer Kopie der echten Geschäftsdaten durchgeführt werden. Enterprise-Frameworks wie Spring bieten hier auch Möglichkeiten zum einfachen Importieren von Testdaten vor einem Testlauf.