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. TL;DR Bei bestehenden
Java-EE-Anwendungen starte ich mit schnellen Unit-Tests für die
Fachlogik und ergänze schrittweise Tests für die Infrastruktur.
Über Konstruktor-Injection kannst du Abhängigkeiten direkt
übergeben und Klassen im Java-SE-Kontext testen. Echte
Implementierungen kommen infrage, wenn sie schnell und zuverlässig
laufen; Zugriffe auf externe Ressourcen ersetze ich zunächst durch
Test doubles. Arquillian verwende ich für wenige umfassende Tests
im Application-Server, die auch das Zusammenspiel mit der echten
Datenbank prüfen. Kapitelmarken [00:00:01] Einstieg ins Testen von
Java-EE-Anwendungen [00:02:34] Matthias Bünger und sein
Arbeitsumfeld [00:05:09] Aufbau der Backend-Anwendung und
XML-Verarbeitung [00:07:57] Vorhandene Tests und Fragen zu
Arquillian und Mocking [00:10:50] Von der Fachlogik nach außen
testen [00:13:39] Automatische Regressionstests und reproduzierbare
Testdaten [00:15:59] Aufwand und Einsatz von Arquillian [00:18:05]
Domäne isolieren und Komponenten verbinden [00:19:39] Persistenz
mit lokalen und echten Datenbanken testen [00:21:11] Testpyramide
und vollständige Benutzerabläufe [00:22:28] CDI und Logging im
bestehenden Projekt [00:24:12] Abhängigkeiten durch
Konstruktor-Injection sichtbar machen [00:27:09] Logger übergeben
und bestehende Klassen testbar machen [00:29:48] Objekte und
Abhängigkeiten im Test vorbereiten [00:32:10] Lesbare Tests mit
sprechenden Hilfsmethoden [00:33:59] Welche Abhängigkeiten werden
gemockt? [00:38:43] Schnelle Tests und Infrastrukturtests getrennt
halten [00:40:16] Den Einstieg auf Fachlogik und kurze Laufzeiten
ausrichten [00:42:48] Oracle oder lokale Datenbank als Testziel
[00:45:01] Datenbankrechte und getrennte Testkonfigurationen
[00:46:12] JPA im Java-SE-Kontext mit eigenem EntityManager
[00:49:10] Datenbanktests mit Arquillian abwägen [00:51:34]
Umfangreiche Mock-Setups als Anlass zum Refactoring [00:54:17]
Austauschbare Abhängigkeiten früh einplanen [00:56:16] Quellen zum
Testen und Unterschiede zwischen Stubs und Mocks [00:58:54] Mockito
als Framework für den Einstieg [01:00:36] Clean Code und Continuous
Integration [01:02:21] Maven und plattformunabhängige Builds
[01:04:07] Kontakt und Fragen zur Episode [01:05:14] Praktische
Ausbildung und Hürden beim Einstieg [01:07:16] Weitere Fragen und
Shownotes 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 Zusammenfassung Ausgangspunkt: Eine
bestehende Java-EE-Anwendung testen Im Gespräch mit Matthias Bünger
gebe ich dir Einblicke aus meinen Projekten. Matthias arbeitet beim
ITZ Bund an einer Backend-Anwendung, die XML-Dateien mit Meldungen
zu Freistellungsaufträgen einliest und über JPA in einer
relationalen Datenbank verarbeitet. Durch hohe Last und parallele
Abläufe entstehen besondere Herausforderungen. Die vorhandenen
Unit-Tests prüfen vor allem Hilfsfunktionen für Strings; die
fachlichen Regeln sollen zusätzlich automatisch getestet werden.
Mit automatischen Tests kannst du nach Änderungen auch bereits
vorhandene Funktionen erneut prüfen. Das hilft etwa bei einem
Hotfix. Für reproduzierbare Ergebnisse brauchst du definierte
Testdaten und einen Ausgangszustand, den du vor jedem Test
wiederherstellst. Mit der Fachlogik beginnen Für den Einstieg
arbeite ich mich von der fachlichen Domäne nach außen vor. Eine
Berechnung lässt sich mit einem selbst erzeugten Java-Objekt
testen, dessen Eigenschaften du passend zum Testfall setzt. Die
Domäne sollte möglichst frei von technischen Abhängigkeiten sein,
damit solche Tests direkt im Java-SE-Kontext laufen. Anschließend
verbinde ich Komponenten miteinander und prüfe ihre Zusammenarbeit.
Sobald eine Komponente auf Infrastruktur zugreift, ersetze ich
diese Abhängigkeit zunächst durch ein Test double. Ein Repository
kann beispielsweise vorgegebene Datensätze liefern. Bei einer neuen
Anforderung habe ich auch schon mit einem umfassenden
Integrationstest begonnen, wie es im Buch Growing Object-Oriented
Software, Guided by Tests beschrieben wird. Dieser Test bleibt
zunächst rot, während kleinere Unit-Tests die einzelnen Schritte
begleiten. Sobald der große Test erfolgreich durchläuft,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.