Wie steigt man in das automatisierte Testen einer Java-EE-Anwendung ein, wenn man bereits eine bestehende Anwendung hat und bislang nicht getestet hat? Diese und weitere Fragen kläre ich im Interview mit Matthias Bünger in der einhundertachtundzwanzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du?

Matthias Bünger, aus Bonn, beschäftigt beim ITZBund (Informationstechnikzentrum Bund, IT-Dienstleister).

An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?

Qualitätssicherung, Buildmanagement, automatisches Testen.

Automatisierung ist mir sehr wichtig. Ich möchte die Grundlagen für automatische Tests schaffen.

Ansonsten bin ich hauptsächlich in der Backend-Anwendung tätig.

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Nach der Schule habe ich eine Ausbildung zum Fachinformatiker Anwendungsentwicklung absolviert.

Danach habe ich noch Informatik studiert.

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Java (EE)

Was ist deine Lieblingsprogrammiersprache und warum?

Java

Automatisiertes Testen von Java-EE-Anwendungen

Mein aktueller Wissensstand zum Testen ist etwas durcheinander. Ich bin verwirrt durch zahlreiche Blog-Beiträge, die unterschiedliche Meinungen propagieren. Zum Beispiel: "Mocke nur, was du unter Kontrolle hast!" oder "Mocks sind gemacht worden, um sie wieder abzuschaffen!". Ja was denn nun?

Gibt es aktuell noch gar keine Tests in eurer Anwendung?

Es gibt ein paar Unit-Tests ohne Mocking oder Dependency Injection.

In vielen Komponenten werden Logger eingesetzt, die die Tests erschweren.

Ich habe eine Schulung zu Arquillian besucht und kann theoretisch damit loslegen.

Was mich abschreckt ist das Deployment bei Arquillian, das recht lange dauert.

Was macht die Anwendung überhaupt? Welche Frameworks/Technologien werden eingesetzt?

Backend zur Verarbeitung von XML-Dateien, die ins Dateisystem geliefert werden.

Die Daten aus den XML-Dateien werden dann mit JPA in eine Datenbank geschrieben, von wo aus sie weiter verarbeitet werden.

Fachlich geht es um Freistellungsaufträge von Banken.

Unsere Herausforderungen sind die parallele Verarbeitung und eine hohe Last. Im Hintergrund läuft WebSphere.

Die fachliche Logik ist nicht allzu komplex.

Was sind deine Herausforderungen beim Testen?

Wir verwenden häufig einen Logging Interceptor. Wie mockt man den?

Wir setzen stark auf CDI mit @Inject an den Attributen. Wie testet man das?

Ansonsten gibt es viele Data Access Objects.

DB-Zustände müssen evtl. zum Testen hergestellt und danach zurückgesetzt werden.

Wie findet man einen Einstieg ins Testen?

Ich würde mit Unit-Tests für die Fachlichkeit beginnen. Dieser Teil der Anwendung "verdient das Geld".

Die EE-Technik geht eher nicht kaputt und muss nicht zu Beginn getestet werden. Das bringt kaum Mehrwert.

Ich würde nicht mit Arquillian beginnen, sondern mit "einfachen" Unit-Tests mit JUnit, ggfs. unterstützt durch Mocks mit Mockito.

Was mockst du?

Ich habe verschiedene Meinung gelesen: Nur mocken, was man vollständig versteht. Niemals Fremdimplementierungen mocken. Keine Legacy-Anwendungen mocken.

Das sehe ich anders: Ich mocke alles, was mir im Weg steht und insb. die Infrastruktur berührt (Netzwerk, Datenbank, Dateisystem).

Wenn die Mocks zu aufwändig werden, ist das ein Zeichen dafür, dass die zu testende Klasse verkleinert werden muss.

Würdest du auch die Datenbank mocken?

Erstmal ja, um die Tests zu beschleunigen.

Aber danach würde ich gegen eine lokale oder In-Memory-DB testen und am Schluss auch gegen eine "echte" Datenbank, z.B. eine Entwicklungsdatenbank.

Die jeweilige Zieldatenbank (z.B. Oracle) ist halt nicht H2. Die Systeme verhalten sich unterschiedlich. Und wichtig ist, dass die Software später auf dem echten Zielsystem lauffähig ist.

Ich würde die echten DB-Tests aber nicht mit EE im Application Server laufen lassen,