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
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.