Testen von Java-EE-Anwendungen mit Matthias Bünger – Anwendungsentwickler-Podcast #128

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, sondern komplett ohne
Arquillian mit einem JPA-Provider wie EclipseLink oder
Hibernate im SE-Kontext. Das ist schneller als ein komplettes
Deployment.



Welche DB-Benutzer verwendest du zum Testen?

Technische User mit erweiterten Rechten zum Anlegen von
Schemas, z.B. bei DB-Migrations nötig.

Ich setze auf zwei verschiedene Persistence-Units für
main und test, damit der Produktivcode keine Ahnung von der
zweiten DB haben muss.



Welche Ressourcen kannst du zum Thema empfehlen?

„Test automation without a headache: Five key patterns“
von Gojko Adzic auf der „Norwegian Developers Conference
2016“ in London

Martin Fowler – Mocks Aren’t Stubs: Hier werden die
Begriffe Stub, Mock, Spike usw. erklärt und abgegrenzt, da
sie häufig falsch benutzt werden.



Hast du eine allgemeine Buchempfehlung?

Clean Code* finde ich sehr wichtig, auch wenn ich nicht
alle Inhalte teile. Ich habe daraufhin CheckStyle usw.
eingeführt und achte mehr auf Code-Qualität und Wartbarkeit.

Alles rund um Continuous Integration! Automatisierung ist
viel wert! Einmal aufsetzen, für immer die Vorteile genießen.
Für mich wichtig ist die erreichte Plattformunabhängigkeit,
keine Dependencies, die ich im Classpath manuell setzen muss
etc. Bei uns kann mit Git und Maven jeder direkt in neue
Projekte einsteigen. Außerdem findet der CI-Prozess auch
Fehler in den Projekten.



Abschluss

Wo können die Hörer mehr über dich erfahren bzw. dich
kontaktieren?

Ich bin nicht online vertreten. Facebook halte ich
privat. Höchstens bei StackOverflow oder bei einer Bewerbung
auf unsere Stellenausschreibungen!



Literaturempfehlungen * Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Test automation without a headache: Five key patterns von
Gojko Adzic auf der „Norwegian Developers Conference 2016“ in
London

Mocks Aren’t Stubs von Martin Fowler

100% Code Coverage – TDD mit Java EE von Stefan Macke auf der
JavaLand 2018