Dev Services statt manueller Testinfrastruktur

Dev Services statt manueller Testinfrastruktur

0:00 Es gibt einen Moment, in dem Quarkus die meisten Menschen zum ersten Mal wirklich überrascht: Man startet die Anwendung, ohne eine Datenbank gestartet zu haben — und sie läuft trotzdem. Das wirkt wie ein Trick, ist aber eine sehr genaue Regel, und die schauen wir uns jetzt an. Danach geht es um die ehrliche Abgrenzung zu dem, was Spring Boot mit Service Connections und Docker-Compose-Unterstützung inzwischen selbst bietet — und um die Frage, was davon in der Pipeline trägt.

Dev Services statt manueller Testinfrastruktur

0:25 Direkt nach dem Testmodul, und das ist kein Zufall: Tests, die eine mühsam gepflegte Infrastruktur brauchen, werden seltener ausgeführt. Dieses Modul räumt genau diese Hürde weg. Danach schließen wir den zweiten Tag mit Security und Messaging ab — beides Themen, für die uns die Dev Services gleich noch nützlich sein werden.

Konzept und Bausteine

0:45 Beginnen wir mit der Regel selbst. Sie ist überraschend einfach, und sie erklärt auch, warum Dev Services manchmal eben nicht anspringen. Die Regel lautet: Ist eine Extension eingebunden, aber nicht konfiguriert, startet Quarkus den zugehörigen Dienst selbst — in der Regel als Container. Das Fehlen von Konfiguration ist hier also kein Fehler, sondern der Auslöser. Voraussetzung sind eine Container-Laufzeit und der Entwicklungs- oder Testmodus.

1:12 Das Bild: ein Hotelzimmer, in dem das Licht angeht, sobald Sie die Karte stecken — solange Sie nicht selbst einen Schalter umgelegt haben. Wer einmal halb konfiguriert, bekommt weder das eine noch das andere. Diese vier Kästen sind die Prüfliste für den Fall, dass nichts passiert. Gehen Sie sie in dieser Reihenfolge durch: Ist die Extension wirklich drin?

1:34 Steht vielleicht doch noch eine Verbindungsangabe irgendwo — auch in einem Profil, auch als Umgebungsvariable? Läuft der richtige Modus? Und läuft eine Container-Laufzeit? In neun von zehn Fällen liegt es am zweiten Kasten, und die Verbindungsangabe steht in einer Datei, die jemand vor Monaten angelegt hat. Der vierte Kasten ist der Punkt, an dem Quarkus die Verbindungsdaten selbst einträgt — deshalb müssen Sie nichts weiter tun.

2:00 Der praktische Gewinn ist nicht, dass ein Container startet — das kann Compose auch. Der Gewinn liegt darin, dass die Verbindungsdaten nicht gepflegt werden müssen: Sie entstehen beim Start und werden automatisch verdrahtet. Damit verschwindet eine ganze Klasse von Einrichtungsproblemen, und wer das Projekt neu auscheckt, braucht keine Anleitung.

2:20 Wichtig für die Beruhigung im Betrieb: In Produktion greift davon nichts. Dev Services stecken in den Deployment-Modulen und sind im ausgelieferten Artefakt schlicht nicht aktiv. Und abschalten lässt sich alles mit einem einzigen Schlüssel. Der erste Punkt ist der häufigste Supportfall: eine halb gesetzte Konfiguration, und der Dev Service bleibt stumm.

2:41 Der zweite ist banal und passiert trotzdem — die Container-Laufzeit fehlt, und die Schuld bekommt das Framework. Der dritte betrifft langsame Netze oder große Images: Der Start überschreitet das Zeitlimit; das lässt sich hochsetzen, man muss nur wissen, dass es das gibt. Und der vierte ist ein Denkfehler, der teuer werden kann: Im Produktionsprofil wird ein Dev Service erwartet, den es dort nie geben wird.

Datenbank, Broker und Identity Provider

3:05 Sehen wir uns an, für welche Dienste es das gibt — und wie man eingreift, wenn die Voreinstellung nicht reicht. Die Liste ist lang und deckt praktisch alles ab, was ein typischer Dienst braucht: die üblichen relationalen Datenbanken, die verbreiteten Message Broker, verschiedene NoSQL-Systeme, dazu Keycloak für die Anmeldung.

3:24 Für unser Beispiel Pfandkreis heißt das konkret: Datenbank, Broker und Identity Provider sind abgedeckt — also genau die drei Container, die heute in der Compose-Datei stehen. Das ist die Grundlage der Übung in diesem Modul. Beachten Sie, dass diese Liste über die Zeit wächst — sehen Sie also nach, bevor Sie für einen Dienst von Hand einen Container einrichten.

3:44 Und was nicht in der Liste steht, lässt sich weiterhin über eine Testressource bereitstellen. Der wichtigste Hinweis steht in der Fußnote: Gesetzt wird nur, was wirklich abweicht. Ohne Angabe wählt Quarkus ein passendes Image, und meistens ist das richtig. Zwei Einstellungen lohnen sich trotzdem fast immer. Erstens der Image-Name mit festem Tag — damit ändert sich Ihre Datenbankversion nicht zwischen zwei Testläufen.

4:09 Zweitens die gemeinsame Nutzung, wenn mehrere Anwendungen denselben Broker meinen. Und die Wiederverwendung zwischen Läufen ist verlockend; sie hat aber eine Nebenwirkung, über die wir gleich sprechen. Die drei Dienste haben in unserem Projekt klare Rollen. Die Datenbank trägt das Schema, das Flyway beim Start migriert — Sie testen also gegen dieselbe Schemafolge wie in Produktion.

4:32 Der Broker ersetzt die Infrastruktur für Producer und Consumer, was das Messaging-Modul deutlich vereinfacht. Und der Identity Provider liefert echte Tokens; das ist wichtiger als es klingt, denn ein gesetzter Testbenutzer prüft den Tokenpfad eben nicht. Der letzte Punkt betrifft Teams: Mit gemeinsamer Nutzung teilen sich mehrere Anwendungen einen Container statt jeweils einen eigenen zu starten.

4:55 Der erste Punkt ist der wichtigste für reproduzierbare Tests: Ohne festes Image-Tag ändert sich die Datenbankversion unbemerkt, und irgendwann bricht ein Test aus Gründen, die niemand versteht. Der zweite ist eine Ressourcenverschwendung — zwei Anwendungen starten je einen Broker, obwohl sie denselben meinen. Der dritte ist eine verpasste Gelegenheit: Der Identity Provider wird gemockt, obwohl ein echter zur Verfügung stünde.

5:19 Und der vierte ist eine Fehlnutzung: Dev Services für Lasttests. Die Zahlen daraus sagen nichts über Produktion.

Abgrenzung zu Spring Boot und Einsatz in CI

5:26 Jetzt der faire Vergleich. Spring Boot hat in diesem Bereich in den letzten Jahren deutlich aufgeholt — sehen wir uns an, worin der Unterschied tatsächlich besteht. Beide Plattformen setzen auf dieselbe technische Grundlage. Spring Boot bietet Service Connections und die Compose-Unterstützung, Quarkus die Dev Services. Der Unterschied liegt nicht im Prinzip, sondern darin, wo die Definition steht und wer den Lebenszyklus steuert.

5:52 Deshalb sollte der Vergleich nicht als modern gegen veraltet geführt werden — das wäre unredlich und hilft niemandem bei der Entscheidung. Die nützliche Frage lautet: Welche Variante passt zu der Art, wie Ihr Team arbeitet? Links steht die explizite Variante: Eine Definition im Projekt, sichtbar im Code oder in einer Datei, mit bewusst gewähltem Image.

6:13 Rechts die implizite: Die Extension bringt Vorgaben mit, und Sie greifen nur ein, wo nötig. Der Zielkonflikt ist derselbe wie überall zwischen Konvention und Konfiguration. Explizit heißt: mehr Schreibarbeit, dafür steht alles da. Implizit heißt: nichts zu tun, dafür muss man wissen, was im Hintergrund entschieden wird.

6:34 Beides ist vertretbar — solange es im Team eine bewusste Entscheidung ist und keine Zufälligkeit. Für die Pipeline gibt es drei konkrete Punkte. Erstens braucht die Wiederverwendung von Containern einen Eintrag in einer Properties-Datei — das ist nicht allein eine Quarkus-Einstellung. Zweitens, und das ist die Warnung: Bei Wiederverwendung wird das Datenbankschema nicht zurückgesetzt. Sie sparen Startzeit und bezahlen mit Isolation.

7:00 Für lokale Entwicklung ist das oft ein guter Handel, für die CI selten. Und drittens: Auf Runnern ohne Zugriff auf eine Container-Laufzeit funktioniert nichts davon; das muss man wissen, bevor man die Compose-Datei löscht. Der erste Punkt ist die direkte Folge der letzten Folie: Wiederverwendung ist eingeschaltet, und Tests beeinflussen sich über alte Daten — mit dem unangenehmen Effekt, dass die Suite je nach Reihenfolge unterschiedlich ausgeht.

7:26 Der zweite fällt erst in der CI auf. Der dritte ist eine Haltungsfrage: Wer den Vergleich mit Spring Boot als Wettbewerb führt, verliert die eigentliche Frage aus dem Blick. Und der vierte ist eine Kostenfalle: Wenn Images bei jedem Lauf neu geladen werden, dominiert das Herunterladen die Laufzeit der Pipeline.

Übung

7:44 In der Übung lösen wir die handgepflegte Testinfrastruktur von Pfandkreis ab — und messen, ob sich das lohnt. Die Aufgabe ist überschaubar, das Erfolgskriterium hat es in sich: Die Testsuite muss grün bleiben, und Sie sollen Laufzeiten vorher und nachher notieren. Genau dieser Vergleich fehlt in der Praxis fast immer — man stellt um, weil es eleganter wirkt, und weiß hinterher nicht, ob es schneller geworden ist.

8:08 Wer Zeit übrig hat, schaltet zusätzlich die Wiederverwendung ein und prüft, ob die Tests danach noch unabhängig voneinander sind. Die Antwort wird manche überraschen. Der erste Schritt ist der, bei dem es meistens hakt: Die Verbindungsdaten müssen wirklich weg, nicht nur auskommentiert — und zwar in allen Profilen. Danach die Extensions prüfen, den Testlauf starten und zusehen, welche Container hochkommen. Im vierten Schritt nageln Sie die Image-Namen dort fest, wo die Version zählt.

8:37 Und im fünften vergleichen Sie mit dem bisherigen Setup. Die Fußnote nennt die Entscheidung, die daraus folgt: Kann die Compose-Datei ganz weg? Wenn ja, löschen Sie sie. Eine Datei, die niemand mehr pflegt, wird sonst irgendwann wieder benutzt. Der erste und zweite Punkt gehören zusammen: Die alte Datei bleibt liegen, die Verbindungsdaten sind nur auskommentiert — und in drei Monaten läuft wieder jemand mit dem alten Setup.

9:02 Der dritte ist der schon erwähnte fehlende Image-Tag, der Testläufe unvergleichbar macht. Und der vierte ist der eigentliche Punkt dieser Übung: Wenn der Laufzeitvergleich ausfällt, bleibt die Bewertung Gefühlssache — und Gefühlssachen lassen sich im Team schlecht diskutieren. Und ein letzter Punkt, der über die Übung hinausgeht: Halten Sie fest, was Sie gemessen haben, und zwar im Repository.

9:24 Die nächste Person, die über die Compose-Datei stolpert, soll die Begründung finden und nicht die Diskussion neu beginnen.