Anwendungen mit Quarkus testen

Anwendungen mit Quarkus testen

0:00 Dieses Modul ist das wichtigste des ganzen Seminars, auch wenn es nicht so klingt. Denn Tests entscheiden darüber, ob eine Migration nachweisbar ist oder nur behauptet. Ohne sie haben Sie am Ende neuen Code und ein gutes Gefühl — aber keine Aussage darüber, ob die Anwendung noch dasselbe tut. Wir sehen uns an, wie Tests in Quarkus funktionieren, wo die Unterschiede zu Spring Boot liegen, und vor allem: wie man das Verhalten einer Anwendung festhält, bevor man sie anfasst.

Anwendungen mit Quarkus testen

0:28 Wir sind in der Mitte des zweiten Tages. Persistenz und Querschnittliches stehen, jetzt kommt das Sicherheitsnetz. Danach ersetzen wir die Testinfrastruktur durch Dev Services — was gut passt, denn beides gehört zusammen: Erst wenn Tests einfach zu starten sind, werden sie auch ausgeführt.

Von SpringBootTest zu QuarkusTest

0:45 Beginnen wir mit den zwei Testarten, die Quarkus anbietet. Der Unterschied zwischen ihnen ist größer als der Name vermuten lässt — und er hat praktische Folgen für Ihre Build-Konfiguration. Die erste Variante startet die Anwendung einmal je Testklasse; Sie können injizieren und per HTTP zugreifen — das ist das Gegenstück zu dem, was Sie aus Spring Boot kennen.

1:07 Die zweite Variante ist etwas anderes: Sie prüft das fertige Artefakt, also das JAR, das Native Executable oder den Container, als Black Box in einem eigenen Prozess. Das Bild: Die erste testet die Küche, die zweite das Gericht, das ausgeliefert wurde. Und ein Hinweis, der Zeit spart: Spring-Boot-eigene Testfunktionen deckt die Kompatibilitätsschicht nicht ab.

1:29 Die Tabelle klärt vor allem zwei praktische Fragen. Erstens: In der Black-Box-Variante können Sie nichts injizieren — der Test läuft in einem anderen Prozess als die Anwendung. Das ist keine Einschränkung, sondern die Definition von Black Box. Zweitens, und das steht in der Fußnote: Die beiden Arten gehören in getrennte Testläufe, die eine in den normalen Testlauf, die andere in die Verifikationsphase.

1:53 Wer das vermischt, bekommt Fehler, die schwer zu deuten sind. Diese Trennung einmal richtig einzurichten, ist eine halbe Stunde Arbeit für das ganze Projekt. Die gute Nachricht für Spring-Teams: Es ändert sich weniger, als man befürchtet. JUnit bleibt, Ihre Testmethoden bleiben, und REST Assured ist auch hier das Standardwerkzeug — es kennt den Port sogar von selbst.

2:15 Zwei Annehmlichkeiten lohnen den Blick: URL und Endpunktpfad lassen sich injizieren, statt sie als Zeichenkette zu wiederholen; damit brechen Tests nicht, wenn sich ein Pfad ändert. Und es gibt eine Annotation, die einen Test in eine Transaktion setzt und danach zurückrollt — das macht Datenbanktests unabhängig voneinander, ohne dass Sie aufräumen müssen.

2:36 Der erste Punkt ist typisch für die Kompatibilitätsstufe: Spring-Boot-Testannotationen bleiben im Code stehen und werden ignoriert. Sie sehen dann Tests, die grün sind, ohne zu tun, was ihr Name verspricht. Der zweite und dritte betreffen die eben besprochene Trennung der Testarten. Und der vierte ist ein Performanceproblem mit Ansage: Jede Testklasse mit abweichender Konfiguration erzwingt einen neuen Anwendungsstart.

3:00 Wer großzügig mit Testprofilen umgeht, hat am Ende eine Suite, die niemand mehr lokal ausführt.

Mocks, REST Assured und Testprofile

3:07 Weiter mit dem Handwerkszeug: Wie ersetzt man Abhängigkeiten, und wie bekommt man abweichende Konfiguration in einen Test? Es gibt drei Wege zum Mock, und sie unterscheiden sich in Komfort und Reichweite. Der erste nutzt CDI-Alternativen im Testverzeichnis — einfach, aber mit einer wichtigen Einschränkung, dazu gleich. Der zweite erlaubt, einen Mock zur Laufzeit zu setzen.

3:29 Der dritte ist der bequemste und für Mockito-Nutzer der naheliegende. Dazu kommt das Testprofil: eine Klasse, die abweichende Konfiguration kapselt, statt sie über Testmethoden zu verstreuen. Die Wahl ist keine Geschmacksfrage: Der erste Weg ist am schnellsten geschrieben und fällt beim Native-Test aus, der dritte ist der bequemste und braucht eine zusätzliche Abhängigkeit.

3:52 Das Muster hier werden Sie sofort wiedererkennen, wenn Sie mit Mockito und REST Assured gearbeitet haben — und genau das ist die Botschaft: Ihr Testwissen zieht mit um. Interessanter als der Code ist die Fußnote. Eine Bean im Singleton-Scope lässt sich nur mit einer zusätzlichen Einstellung ersetzen. Das ist genau der Fall, der bei der Migration von Spring-Annotationen eintritt — denn die werden ja standardmäßig auf Singleton abgebildet.

4:16 Wenn ein Mock also unerklärlich nicht greift, liegt es mit hoher Wahrscheinlichkeit hier. Testprofile lösen ein echtes Problem: Konfiguration gehört nicht in Testmethoden. Externe Systeme wiederum kommen über Testressourcen — das sind Klassen, die vor der Anwendung starten und etwa einen Container oder einen HTTP-Stub bereitstellen.

4:36 Der letzte Punkt ist der, den man im Blick behalten muss: Jedes zusätzliche Profil bedeutet einen weiteren Anwendungsstart. Bei drei Profilen merkt man das nicht, bei dreißig schon. Gruppieren Sie Tests deshalb nach Konfiguration, nicht nach Gefühl. Der erste Punkt ist eine Falle mit Spätfolgen: CDI-Alternativen funktionieren im Native-Test nicht. Wer seine Testsuite darauf aufbaut, kann das Artefakt später nicht mehr prüfen.

5:02 Der zweite ist die eben erwähnte Profilinflation. Der dritte ist ein Klassiker jeder Mocking-Bibliothek — ein Mock bleibt über Testklassen hinweg stehen und verfälscht andere Tests. Und der vierte betrifft die Aussagekraft: Es werden Statuscodes geprüft, aber nicht das Antwortformat. Genau daran scheitert später der Vergleich zwischen alter und neuer Variante.

Charakterisieren statt hoffen

5:25 Und jetzt zum Kern. Nicht: Wie schreibt man Tests in Quarkus? Sondern: Welche Tests brauchen Sie, um eine Migration überhaupt nachweisen zu können? Ein Characterization Test beschreibt das heutige Verhalten, ohne es zu bewerten. Das klingt banal, ist aber ein Haltungswechsel: Sie schreiben keinen Test dafür, was die Anwendung tun sollte, sondern dafür, was sie tatsächlich tut — Eigenheiten inbegriffen.

5:50 Das Bild: Sie fotografieren ein Zimmer, bevor die Handwerker kommen. Nicht, weil das Zimmer perfekt wäre, sondern damit hinterher niemand diskutieren muss, wie es vorher aussah. Für eine Migration ist das der einzige belastbare Maßstab. Die fünf Schritte haben eine klare Reihenfolge, und der erste ist der, an dem am meisten schiefgeht: Wählen Sie die fachlich wichtigsten Abläufe, nicht die technisch einfachsten.

6:15 Es ist verlockend, mit dem zu beginnen, was sich leicht testen lässt — aber das sind selten die Abläufe, bei denen ein Fehler weh tut. Fehlerfälle und Antwortformate gehören ausdrücklich dazu. Und dann der entscheidende Teil: erst gegen die alte Variante grün bekommen, dann gegen die neue laufen lassen. Erst wenn beide Varianten dieselben Tests bestehen, ist die Migration nachgewiesen.

6:37 Eine kurze Einordnung, damit die Suite nicht aus dem Ruder läuft. Unit-Tests brauchen keinen Quarkus-Start — halten Sie diese Ebene groß und schnell. Die mittlere Ebene deckt Zusammenspiel, Konfiguration und Endpunkte ab; das ist der Bereich, in dem die meisten Migrationsfehler sichtbar werden. Die Black-Box-Ebene prüft, was wirklich ausgeliefert wird, und ist der einzige Weg, ein Native Image zu testen. Drei Ebenen, drei Aufgaben.

7:04 Wer alles auf eine Ebene legt, bekommt entweder eine langsame oder eine aussageschwache Suite. Der erste Punkt ist der fatalste und passiert häufiger, als man denkt: Die Tests entstehen erst nach dem Umbau. Dann beschreiben sie den neuen Stand — und beweisen nichts. Der zweite ist die übliche Lücke beim Fehlerfall. Der dritte ist handwerklich: Zeitabhängige Werte machen Tests unzuverlässig, und eine unzuverlässige Suite wird bald ignoriert.

7:31 Und der vierte ist organisatorisch: Die alte Variante wird abgeschaltet, bevor der Vergleich gelaufen ist. Halten Sie sie so lange am Leben, wie Sie noch vergleichen wollen.

Übung

7:42 In der Übung bauen wir das Sicherheitsnetz, auf dem die Migration in Modul siebzehn stehen wird. Der Hinweis auf dieser Folie ist die eigentliche Lektion: erst die Tests, dann der Umbau. Wer die Reihenfolge tauscht, hat keinen Vergleichsmaßstab mehr — und merkt das erst, wenn jemand fragt, ob denn nun alles noch funktioniert.

8:01 Ihr Erfolgskriterium ist entsprechend streng: Die Characterization Tests müssen gegen beide Varianten identisch laufen, und mindestens ein Test prüft das fertige Artefakt, nicht nur die laufende Anwendung. Und noch ein praktischer Rat: Legen Sie die Tests in ein eigenes Verzeichnis, das später beide Varianten bedienen kann.

8:19 Ein Test, der nur zur alten oder nur zur neuen Anwendung passt, kann per Definition nicht vergleichen. Drei Abläufe genügen für den Anfang — lieber drei aussagekräftige als zwanzig oberflächliche. Beachten Sie den vierten Schritt: Fremdsysteme werden ersetzt, entweder durch einen Mock oder durch eine Testressource. Ein Test, der ein echtes Fremdsystem aufruft, ist kein Test, sondern eine Wette. Und der fünfte Schritt ist der, den man gern verschiebt, weil er den Build verlängert.

8:49 Tun Sie es trotzdem: Er ist der Einzige, der prüft, was Sie tatsächlich ausliefern. Die Fußnote sagt, wofür das alles gut ist — diese Suite ist Ihre Abnahmebedingung. Vier Punkte für die Nachbesprechung. Tests, die Implementierungsdetails prüfen, brechen bei der Migration, obwohl sich das Verhalten gar nicht geändert hat — und kosten dann Zeit, ohne Erkenntnis zu liefern.

9:11 Echte Aufrufe an Fremdsysteme machen die Suite unzuverlässig. Der Integrationstest wird weggelassen, weil er den Build verlängert — und damit fehlt genau die Ebene, die das Native Image absichert. Und der letzte Punkt ist mehr als ein Stil-Hinweis: Testdaten aus der Produktion sind ein Datenschutzproblem, kein Abkürzungstrick.