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.

Podcast: Play in new window | Download (Duration: 1:09:09 — 31.2MB)

Abonnieren: Apple Podcasts | Spotify | RSS

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