Auch die Seite der Mitfahrgesuche soll eine Störung überstehen, ohne technische Fehlermeldungen zu zeigen. In diesen Übungen ordnest Du Log-Meldungen den passenden Stufen zu und sagst voraus, welche Meldungen erscheinen, schreibst einen @ControllerAdvice mit Störungsseite und Tests für die Gesuche und rekonstruierst aus Log und Health-Abfragen, was bei einer Störung am Montagmorgen passiert ist.
Ein Neustart der Datenbank genügt, und der Flurmonitor zeigt eine „Whitelabel Error Page“, ein falsch eingerichteter Monitor sogar JSON. In diesem Artikel wird der Monitor robust: Eigene Fehlerseiten ersetzen die Seiten von Spring Boot, und ein @ControllerAdvice zeigt bei einer Störung einen verständlichen Hinweis. Logging mit SLF4J hält fest, was passiert ist, Spring Boot Actuator meldet über /actuator/health, ob die Anwendung läuft. Ein Pipeline-Job prüft die Templates mit dem Nu Html Checker, und das Team schließt Sprint 2 mit Review und Retrospektive ab.
Übungen zu Abfragen und Integrationstests im Mitfahr-Backend: Du übersetzt Methodennamen in SQL, ordnest Aussagen zu @DataJpaTest ein, schreibst eine JPQL-Abfrage, die zu einer Abfahrtszeit die passenden Mitfahrgesuche findet, testest sie an den Grenzen des Zeitfensters und findest heraus, warum ein Test allein grün und in der Testsuite rot ist und warum ein anderer nur in der Pipeline mit MariaDB scheitert.
Die Repositories aus Artikel 06 können bisher nur, was sie von JpaRepository geerbt haben. Jetzt bekommen sie eigene Abfragen: aus dem Methodennamen abgeleitet oder mit @Query in JPQL geschrieben. Ob diese Abfragen das Richtige finden, prüfen Integrationstests mit @DataJpaTest gegen eine echte Datenbank: H2 beim täglichen Testlauf, MariaDB in der Pipeline. Nebenbei beantwortet GET /angebote endlich Suchanfragen.
Übungen zur Persistenz im Mitfahr-Backend: Du ordnest Java- und Datenbankbegriffe zu, liest das von Hibernate erzeugte SQL für die Tabelle der Mitfahrgesuche, schreibst die Entity Gesuch, ein Repository und die Startdaten in data.sql, deutest eine Fehlermeldung zum Fremdschlüssel, machst die Beziehung zwischen Nutzer und Gesuch in beide Richtungen navigierbar und zeigst, warum EnumType.ORDINAL gespeicherte Daten unbemerkt verfälscht.
Übungen zur Fehlerbehandlung im Mitfahr-Backend: Du ordnest Fehlersituationen rund um Mitfahrgesuche den Statuscodes zu, liest eine Fehlerantwort nach RFC 9457, schreibst einen GesuchMapper und einen GesuchController, findest heraus, warum der Flurmonitor mit Gesuchen plötzlich 500 meldet, und bewertest einen Vorschlag, den Statuscode in die fachlichen Ausnahmen zu verlagern.
Übungen zur Service-Schicht im Mitfahr-Backend: Du erkennst die drei Arten der Dependency Injection, beurteilst Aussagen zu Mocks und Transaktionen, schreibst einen GesuchService mit Konstruktorinjektion und einer injizierten Uhr, testest ihn mit Mockito und findest heraus, warum ein zurückgezogenes Gesuch trotz grüner Tests offen bleibt und warum das Abdeckungs-Gate ein anderes Paket meldet als erwartet.
Bisher speichert der Controller Angebote direkt über die Repositories, und keine der Fachregeln aus Artikel 04 wird geprüft. Jetzt kommt eine Service-Schicht dazwischen: Spring setzt Controller, Services, Repositories und eine Uhr per Konstruktorinjektion zusammen, @Transactional macht aus jeder Buchungsänderung eine Transaktion, und Buchungen lassen sich endlich anfragen, bestätigen und stornieren. Getestet wird der Service mit Mockito ganz ohne Datenbank; ein Abdeckungs-Gate lässt den Build scheitern, wenn die Tests zu wenig prüfen.
Bisher stehen die Haltepunkte fest im Code, und neue Angebote verschwinden beim Neustart. Jetzt bekommt das Mitfahr-Backend eine Datenbank: Aus dem Fachmodell werden JPA-Entities mit Beziehungen, Spring Data erzeugt den Zugriff aus einem leeren Interface, Hibernate legt die Tabellen an, und eine data.sql füllt die H2-Datenbank beim Start mit den Daten des Szenarios. Wer Docker nutzt, startet dieselbe Anwendung mit MariaDB.
Übungen zur Qualitätssicherung im Build des Mitfahr-Backends: Du ordnest Werkzeuge und Pipeline-Begriffe zu, deutest Checkstyle-Meldungen zur Zeitfensterregel der Mitfahrgesuche, liest Anweisungs- und Zweigabdeckung aus einem JaCoCo-Bericht ab, ergänzt eine Regel gegen „magische Zahlen“, passt die GitLab-Pipeline an und zeigst, warum 100 % Abdeckung einen Fehler an der Grenze nicht findet.
Tests helfen nur, wenn sie auch laufen. Der Build des Mitfahrlabors bekommt drei Prüfwerkzeuge: Checkstyle prüft Regeln für den Code, Spotless sorgt für einheitliche Formatierung, JaCoCo misst die Testabdeckung. Alle hängen an der Sammelaufgabe check (Gradle) bzw. der Phase verify (Maven). Eine Pipeline in GitLab CI führt bei jedem Push die Stufen build, test, quality und package aus und zeigt Testergebnisse und Abdeckung im Merge Request.
Übungen zur Fachlogik im Mitfahr-Backend: Du bildest Äquivalenzklassen und Grenzwerte für einen Kostenbeitrag, ordnest JUnit-Zusicherungen zu, schreibst einen parametrisierten Test zur Einwilligung, setzt die Zeitfensterregel für Gesuche samt Tests um, testest die Statuswechsel eines Gesuchs vollständig und findest einen Rundungsfehler, den double verursacht.
Die Regeln, die der API-Vertrag nicht ausdrücken kann, kommen ins Paket domain: der Kostenbeitrag je Kilometer, die Einwilligung bei Minderjährigen und die erlaubten Wechsel des Buchungsstatus. Sie entstehen in reinem Java ohne Spring, mit BigDecimal, LocalDate, einem switch-Ausdruck und eigenen Exceptions. Mit Äquivalenzklassen und Grenzwerten findest Du die Testfälle und prüfst sie mit parametrisierten JUnit-Tests: die erste Testebene des V-Modells, der Komponententest.
Übungen zur Codegenerierung im Mitfahr-Backend: Du ordnest Angaben im Vertrag dem erzeugten Java-Code zu, sagst Statuscodes voraus, bestimmst die erzeugte Schnittstelle für die Gesuche, implementierst sie, entscheidest, welche Regeln Bean Validation prüft, findest Fehler anhand von Symptomen und beurteilst Contract First gegenüber Code First.
Der OpenAPI Generator macht aus dem API-Vertrag Java-Schnittstellen und Datenklassen. Du bindest ihn in Gradle oder Maven ein, lässt den Controller für die Haltepunkte die erzeugte Schnittstelle implementieren und siehst, wie die Regeln aus dem Vertrag als Bean Validation fehlerhafte Anfragen mit 400 abweisen. Weicht der Code vom Vertrag ab, merkt es der Compiler; ist der Vertrag fehlerhaft, bricht der Build ab.
Übungen zum Spring-Boot-Projekt des Mitfahr-Backends: Du ordnest Annotationen und Dateien zu, schreibst einen Controller für Mitfahrgesuche mit Record und Pfadvariable, sagst Antworten auf Anfragen voraus, findest Fehler in einem Controller anhand ihrer Symptome und ergänzt einen Filter über einen Query-Parameter.
Mit dem Spring Initializr entsteht das Projekt für das Mitfahrlabor-Backend. Du lernst die Projektstruktur, den Build mit Gradle oder Maven und die Startklasse kennen, schreibst den ersten REST-Controller für die Haltepunkte von Hand, rufst ihn mit dem Browser, einer .http-Datei oder der Shell auf und lässt den ersten Test laufen: einen Smoke-Test, der prüft, ob die Anwendung überhaupt startet.
Das MVP der Mitfahr-App kennt nur Angebote. In diesen Übungen planst Du die Ressource „Gesuch“ für alle, die kein Auto haben: Du ordnest Entwurf und Test im V-Modell zu, wählst Methoden und Statuscodes, schreibst User Story und Abnahmekriterien, entwirfst Endpunkte und Schemas im OpenAPI-Vertrag, findest Fehler in einem Vertragsausschnitt und zeichnest die Zustände eines Gesuchs.
Bevor die erste Zeile Java entsteht, wird geplant: Aus dem Auftrag werden User Stories mit Abnahmekriterien, aus den Fachregeln ein Fachmodell mit Zustandsdiagramm, aus der Architektur ein Schichtenmodell und aus allem zusammen ein API-Vertrag im Format OpenAPI. Damit ist die linke Seite des V-Modells für das Mitfahrlabor-Backend vollständig, und jede spätere Testebene weiß, wogegen sie prüft.
Das Maven-Projekt wird so konfiguriert, dass nach jedem Unit-Test-Durchlauf die Überdeckungstestmetriken gespeichert und als Report aufbereitet werden.
Es werden Unit-Tests für den REST-Controller erstellt. Dazu wird eine gemockte Umgebung konfiguriert. Das Testframework von Spring mit seinen zahllosen Klassen wird vorgestellt.
Es wird die eigentliche REST-API für unsere Adressen erstellt: Methoden für PUT, GET, POST und DELETE. Die API wird per PowerShell oder Bash aufgerufen, um sie auszuprobieren.
Die zentralen CRUD-Funktionen des Repositories werden getestet. Dazu wird die given-when-then-Methodik verwendet und in jUnit jeweils Testmethoden implementiert.
Es werden die Abhängigkeiten für ein Model angefügt, eine Modelklasse erstellt und annotiert. Die OOP-Hintergründe für Repositories werden kurz an UML-Klassendiagrammen erläutert
Wir implementieren eine API, die wie ein kleiner Bruder antwortet: Allem gesagten wird “Selber” vorangestellt. An diesem dämlichen Beispiel lernen wir einen Controller für GET-Requests und das Unit-Test-Framework jUnit kennen.
Grundlagen zu REST-APIs, Klärung der Begriffe Ressource (Entität in REST), Repräsentation (Darstellungsform, z.B. JSON, XML), HTTP-Methoden (GET, PUT, POST, PATCH, DELETE) und deren Zuordnung zu den CRUD-Operationen, Eigenschaften der Methoden: safe/cacheable/idempotent, Abgrenzung URI/URL/URN, Pfad- und Query-Parameter, HATEOAS, Hypermedia, Aufbau von HTTP-Anfrage und -Antwort (Methode, URL, Header, Body), Statuscodes und typische Fehlerursachen wie 404 und 405.
In zwölf Artikeln entsteht mit Spring Boot das Backend der Mitfahr-App Mitfahrlabor: von den Anforderungen über den OpenAPI-Vertrag bis zur fertigen REST-API. Dabei durchläufst Du jede Testebene des V-Modells einmal, und eine CI-Pipeline wächst mit. Hier findest Du den Fahrplan, die Voraussetzungen und den Überblick über das, was am Ende entsteht.
Mit dem SpringInitializr ein neues Projekt konfigurieren und anlegen, in der Projektstruktur zurechtfinden, einen “Hello World”-Webservice implementieren und starten.
Vorbereiten der Entwicklungsumgebung, Plugins und ein Build-Tool (Maven/Gradle) für Java-Projekte mit Frameworks (z. B. ein SpringBoot-Projekt oder JavaFX): Installation eines aktuellen Java-LTS-JDK (und Eintrag im PATH), VSCodium als IDE mit den für Java nötigen Plugins, Installieren und Überprüfen der Gradle- bzw. Maven-Version sowie der Versionsverwaltung Git.
