Das Unit-Testing

Jetzt schauen wir uns also das Unit-Testing etwas genauer an, und zwar wie das in Java funktioniert.

Da gibt es so ein de facto Standard-Framework und das nennt sich JUnit.

Kurzer Recap, wo befinden wir uns jetzt vor allem beim Komponententesten.

In unserem Kontext ist so eine Komponente eine Klasse.

Kann man auch anders definieren, aber der Normalfall ist, das ist eine Klasse.

Da gibt es jetzt diese TestHarnessJUnit, die ist schon ein bisschen älter,

aber die hatte sehr, sehr großen Einfluss drauf auf dieses Entwicklertesten.

Unit-Tests werden auch Entwicklertests genannt.

Die hat es quasi revolutioniert, weil es für den Entwickler jetzt sehr einfach wurde, Tests selber zu schreiben.

Das Ganze ist objektorientiert, wie immer in Java.

Es ist relativ leicht und eingänglich und auch leicht zu lernen.

Und die modernen Entwicklungsumgebungen wie Eclipse und IntelliJ, die haben da eine sehr gute Integration,

die das Anstarten von diesen Tests sehr einfach macht.

Ja, JUnit gibt es in verschiedenen Visionen.

Wir verwenden JUnit 4 hier noch.

JUnit 5 ist jetzt schon raus seit eineinhalb Jahren, zwei Jahren.

JUnit 4 ist immer noch sehr verbreitet.

JUnit 5 hat dann gewisse Features, wie es verwendet Lambdas.

Es ist eigentlich komplett neu geschrieben worden, hat auch ein modulareres Konzept.

Also man muss nicht immer alles importieren.

Da geht die Entwicklung auf jeden Fall noch sehr voran.

Ich habe hier mal ein Beispiel dabei aus meinem eigenen Projekt.

Da habe ich quasi so einen Scheduler geschrieben.

Der führt immer wieder einen Job aus.

Das heißt, das ist spezifiziert durch ein Datum für die erste Ausführung und dann immer wieder in dem Intervall.

Also zum Beispiel heute um 12 Uhr und dann alle 24 Stunden.

Also im Endeffekt so ähnlich wie ein Kron-Job.

Das soll unsere Komponente sein, die wir testen wollen.

Da gibt es jetzt eine Implementierung, die ist nicht besonders spannend.

Spannender ist dann eigentlich, wie die Tests ausschauen.

Ich habe jetzt zwei Testfälle bzw. zwei Testmethoden.

In JUnit gibt es gewisse Konventionen. Also die Klasse, in der der Test läuft,

die ändert in der Regel immer mit Test.

Und Methoden, die fangen immer mit Test an.

Woher kommt das Ganze? In früheren JUnit Versionen war das eine Konvention, um Tests zu erkennen.

Also diese Annotationen, die ihr hier seht, dieses AddTest, die gibt es noch nicht so lange.

Und diese Konvention, dass man hier für eine Methode immer Tester vorschreibt, die kommt noch daher.

Die hat sich auch irgendwie so gehalten.

Wo liegt das Ganze im Projekt?

Unter einer ähnlichen Ordnerstruktur wie die normale Klasse auch, das mirrort das Ganze quasi.

Bloß nicht unter den Package Main, sondern unter den Package Test.

Dadurch ist es aber auch möglich auf die anderen Klassen in dem Package relativ leicht zuzugreifen.

Also das sollte quasi die Package Hierarchie aus dem Main Package so ein bisschen nachbilden.

Ja, was sieht man jetzt hier?

Ich erstelle mir meinen Input hier oben jeweils in der ersten Zeile.

Dann initialisiere ich meinen Scheduler.

Dann führe ich hier die Methode aus.

Einmal mit einem Datum in der Zukunft, einmal mit einem Datum in der Vergangenheit.

Und zum Schluss mache ich einen Assert.