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.
Die Seite für die Mitfahrgesuche bekommt Integrationstests. In diesen Übungen ordnest Du Tests den Testebenen zu und sagst voraus, woran ein unvollständiger @WebMvcTest scheitert, schreibst Tests für die Gesuche-Seite mit MockMvcTester und HtmlUnit und machst aus den Zetteln einer Retrospektive überprüfbare Maßnahmen, Einträge im Backlog und eine Anpassung des Release-Plans.
Ob Controller, Model und Template zusammenpassen, wissen die Komponententests des Ansichtsmodells nicht. Ein Integrationstest der Web-Schicht schließt diese Lücke: @WebMvcTest startet nur die Web-Schicht, @MockitoBean ersetzt die Aufbereitung durch einen Mock, der genau die Ansicht liefert, die ein Test braucht. Mit MockMvcTester prüfst Du View-Namen, Model-Attribute und HTML, mit HtmlUnit liest Du die Seite wie ein Browser über CSS-Selektoren. Danach endet Sprint 1: Im Sprint Review sieht das Team, was fertig ist und was nicht, und in der Retrospektive leitet es Maßnahmen für Sprint 2 ab.
Der Flurmonitor zeigt bisher alle offenen Fahrten ab heute. Jetzt bekommt die Seite ein eigenes Ansichtsmodell: zwei record-Typen, die genau das enthalten, was das Template braucht, und sonst nichts. Eine kleine Aufbereitung in der Web-Schicht trennt nach Richtung, filtert auf ein Zeitfenster bis zum Ende des nächsten Schultags, sortiert die früheste Abfahrt nach oben und markiert Fahrten mit dem letzten freien Platz. Weil all das von der Uhrzeit abhängt, kommt die Zeit aus einer Clock-Bean; parametrisierte JUnit-Tests mit fester Uhr prüfen die Grenzwerte um Abfahrt und Mitternacht.
Die Seite für die Mitfahrgesuche bekommt ihre Tabelle. In diesen Übungen ordnest Du Thymeleaf-Ausdrücke ihrer Art zu, sagst die Ausgabe einer Schleife mit Statusvariable voraus, baust die Gesuche-Tabelle mit th:each und einem Satz für die leere Liste, stellst die Seite auf Fragmente und Bootstrap als WebJar um und schließt eine Cross-Site-Scripting-Lücke, die th:utext geöffnet hat.
Die Mitfahrgesuche bekommen nach dem Umbau auf Keycloak eigene Zugriffsregeln. In diesen Übungen legst Du Rollen und Regeln für Monitor, REST-API und Verwaltung fest, schreibst Integrationstests mit oidcLogin() und stellst die Anwendung auf einen anderen Keycloak um, findest die Ursachen von 401 und 403 anhand von Symptomen und analysierst die Auswirkungen eines weiteren Change Requests.
Kurz vor Projektende möchte die Schul-IT, dass sich alle im Mitfahrlabor über den Anmeldedienst Keycloak anmelden. Du lernst, wie das Team diesen Change Request mit einer Auswirkungsanalyse bewertet, was OAuth 2.0 und OpenID Connect mit Rollen, Flows und Tokens regeln, wie Du Keycloak startest und wie Spring Security die REST-API als Resource Server mit JWT und die Verwaltungsseite per oauth2Login absichert. Alle Tests laufen als Regressionstests mit, und eine Projekt-Retrospektive schließt das Projekt ab.
Die Mitfahrgesuche auf den Flurmonitoren bekommen Akzeptanztests. In diesen Übungen bestimmst Du die Bestandteile einer Feature-Datei und sagst voraus, welche Schritte Cucumber zuordnen kann, schreibst Szenarien und Step Definitions für die Gesuche je Monitor und wertest das Abnahmeprotokoll eines Sprint Reviews aus.
Die GUI-Tests prüfen den Flurmonitor im Browser, lesen können sie aber nur die Developers. Jetzt schreibt das Team die Abnahmekriterien mit dem Product Owner als Gherkin-Szenarien („Angenommen … Wenn … Dann …“), und Cucumber führt sie mit den vorhandenen Page Objects in Chrome aus. Du lernst, wie Du Abnahmetest und Systemtest abgrenzt, wie gute Szenarien aussehen, wie Step Definitions mit Cucumber Expressions und Spring arbeiten und wie aus dem Cucumber-Bericht ein Abnahmeprotokoll wird. Der erste Lauf findet zwei Abweichungen.
Die Seite der Mitfahrgesuche bekommt eigene GUI-Tests. In diesen Übungen wählst Du Locatoren für ihre Elemente und sagst voraus, was Selenium findet, schreibst ein Page Object und Tests für die Gesuche, lässt den Browser bei einem Fehlschlag ein Bildschirmfoto ablegen und stabilisierst einen Test, der in der Pipeline mal grün und mal rot ist.
Bisher hat das Team im Browser von Hand geprüft, ob die Monitore nachladen und ob sich die Schulverwaltung anmelden kann. In Sprint 3 übernimmt das Selenium WebDriver: Die Tests starten die ganze Anwendung, und ein Chrome ohne Fenster klickt sich durch die Seiten. Du lernst, mit welchen Locatoren Du Elemente stabil findest, warum ein GUI-Test auf Bedingungen wartet statt zu schlafen, wie Page Objects die Tests vom Aufbau der Seiten trennen und wie die Tests in der Pipeline laufen. Gleich der erste Test findet einen Fehler, den kein bisheriger Test bemerkt hat.
Das Organisationsteam soll ein Mitfahrgesuch vom Monitor nehmen können, wenn sich die Person gemeldet hat. In diesen Übungen ordnest Du den Ablauf von Post-Redirect-Get und die Bausteine eines Formulars, schreibst Formular-Objekt, Controller, Template und Tests für „Gesuch zurückziehen“ und findest heraus, warum Hinweise der Schulverwaltung doppelt auf dem Monitor stehen.
Bisher steht der Hinweis der Schulverwaltung fest im Template des Flurmonitors. In diesem Artikel bekommt er eine Entity mit Repository und Service, und der Monitor zeigt nur gültige Hinweise. Neue Hinweise legt die Verwaltung per Formular an: th:object, th:field und th:errors verbinden ein Formular-Objekt mit dem Template, Bean Validation prüft es mit @Valid, und das BindingResult meldet Fehler an die Felder. Nach dem Speichern leitet der Controller um (Post-Redirect-Get), damit Neuladen nichts doppelt anlegt. Eine zweite Filterkette von Spring Security sorgt für Anmeldung und CSRF-Schutz.
Die Seite mit den Mitfahrgesuchen soll sich wie der Flurmonitor selbst aktualisieren. In diesen Übungen ordnest Du Verfahren zum Aktualisieren zu und sagst voraus, wie das Skript auf Fehler reagiert, lieferst die Gesuche-Liste als Thymeleaf-Fragment aus, rüstest die Seite mit Takt und Störungshinweis zum Nachladen aus und findest heraus, warum ein Cache abgelaufene Gesuche auf dem Monitor stehen lässt.
Bisher zeigt der Flurmonitor denselben Stand, bis jemand die Seite neu lädt. In diesem Artikel lädt die Seite zuerst per Meta-Refresh komplett neu, dann holt ein kleines Skript mit fetch alle 30 Sekunden nur den Bereich mit den Abfahrten. Der Controller liefert dafür ein Thymeleaf-Fragment unter einer eigenen Adresse. Scheitert das Nachladen, bleibt der letzte Stand mit einem Hinweis stehen. Damit vier Monitore die Datenbank nicht im Sekundentakt befragen, legt @Cacheable die Abfrage für 20 Sekunden in einen Caffeine-Cache, und @CacheEvict leert ihn, sobald sich ein Angebot ändert.
Die Seite für die Mitfahrgesuche zieht mit dem Flurmonitor nach. In diesen Übungen sagst Du voraus, was Formatierungs- und Nachrichtenausdrücke ausgeben und welche Controller-Methode eine Adresse bedient, richtest die Gesuche-Seite je Monitor mit Pfadvariable und Request-Parameter ein, formatierst ihre Daten und Texte und behebst die Barrierefreiheitsmängel eines Templates.
Im Sprint Review fehlten dem Flurmonitor zwei Dinge: ein Datum, das man aus der Ferne versteht, und Monitore, die je Standort andere Fahrten zeigen. In Sprint 2 wählt der Controller den Monitor über eine Pfadvariable oder Request-Parameter aus, die Einstellungen stehen in application.properties und werden mit @ConfigurationProperties gebunden, und ein Profil stellt die Uhr für Vorführungen fest. Im Template formatiert #temporals Datum und Uhrzeit, Texte kommen mit #{…} aus messages.properties, und Sprache, Überschriften, Tabellenköpfe und Kontrast machen die Seite barrierefrei.
Die Seite für die Mitfahrgesuche bekommt ein eigenes Ansichtsmodell. In diesen Übungen ordnest Du Aufgaben der Service-Schicht, der Aufbereitung, dem Ansichtsmodell und dem Template zu, sagst voraus, welche Fahrten der Monitor am Freitagnachmittag zeigt, baust die Gesuche-Ansicht mit Zeitfenster und Sortierung, prüfst sie mit parametrisierten Tests und einer festen Uhr und findest einen Fehler, der nur zu bestimmten Uhrzeiten auftritt.
Aus der statischen Abfahrtsanzeige wird ein echtes Template: th:each erzeugt für jede offene Fahrt eine Tabellenzeile, th:if zeigt einen Satz statt einer leeren Tabelle, th:classappend hebt die nächste Abfahrt hervor. Der Artikel unterscheidet die Ausdrucksarten ${…}, *{…}, @{…} und #{…}, zeigt, warum th:text vor eingeschleustem HTML schützt und th:utext nicht, lagert Kopf, Navigation, Fußzeile und Tabelle in Fragmente aus und holt Bootstrap als WebJar aus dem eigenen Server statt vom CDN.
Auf dem Flurmonitor sollen neben den Fahrtangeboten auch die Mitfahrgesuche erscheinen. In diesen Übungen bringst Du den Weg einer Anfrage durch Spring MVC in die richtige Reihenfolge, sagst voraus, unter welcher URL Dateien landen und was ein Controller antwortet, legst Controller, Template und Smoke-Test für eine Gesuche-Seite an und findest Fehler anhand ihrer Symptome.
Sprint 1 beginnt: Die Developers zerlegen die erste Story des Flurmonitors in Aufgaben und binden Thymeleaf ins Spring-Boot-Backend ein. Ein @Controller nimmt die Anfrage an, legt Daten ins Model und gibt den Namen eines Templates zurück; Thymeleaf findet das Template unter classpath:/templates/ und rendert daraus HTML. Die statische Abfahrtsanzeige wird zum ersten Template, Stylesheet und Logo werden statische Ressourcen, Spring Security gibt die Seite ohne Anmeldung frei, und ein Smoke-Test prüft, dass das alles zusammen funktioniert.
Nach dem Flurmonitor für Fahrtangebote wartet im Product Backlog das Epic „Mitfahrgesuche auf dem Monitor“. In diesen Übungen ordnest Du Situationen aus dem Projekt den Bestandteilen von Scrum zu, wertest eine Runde Planning Poker aus, schneidest das Epic in User Stories mit Abnahmekriterien, ordnest das Backlog, ergänzt die Definition of Done und planst einen Sprint mit knapper Kapazität.
Bevor der Flurmonitor die erste Zeile Thymeleaf bekommt, startet das Team das Projekt nach Scrum: Es besetzt die Verantwortlichkeiten, formuliert eine Produktvision und ein Produktziel, schreibt das Product Backlog mit User Stories und Abnahmekriterien in der Form Angenommen – Wenn – Dann, vereinbart die Definition of Done, schätzt mit Planning Poker und leitet daraus Release-Plan, Sprint-Ziel und Sprint Backlog für Sprint 1 ab. Dabei zeigt sich, warum die anonyme Anzeige eine Anforderung ist und kein Extra.
In zwölf Artikeln bekommt das Mitfahrlabor-Backend eine erste Oberfläche: einen Flurmonitor, dessen HTML-Seiten der Server selbst mit der Template-Engine Thymeleaf erzeugt. Das Team arbeitet dabei nach Scrum in drei Sprints und prüft den Monitor auf allen Testebenen bis zur Abnahme. Hier findest Du den Fahrplan, die Voraussetzungen und die Einordnung ins Backend.
Übungen zum Änderungsantrag „Anmeldung statt Nutzer-ID“ im Mitfahr-Backend: Du ordnest Anfragen den Statuscodes 401 und 403 zu, analysierst die Auswirkungen auf die Mitfahrgesuche, ergänzt die Regeln der SecurityFilterChain, lässt nur eigene Gesuche zurückziehen, testest den Controller mit @WithMockUser und bewertest HTTP Basic gegenüber OAuth2.
Das Mitfahr-Backend ist abgenommen, da kommt ein Änderungsantrag: Statt die Nutzer-ID im Body mitzuschicken, sollen sich alle anmelden. Der Artikel zeigt, wie eine Auswirkungsanalyse die betroffenen Teile findet, wie der API-Vertrag securitySchemes bekommt und wie Spring Security mit HTTP Basic, Passwort-Hashes und Rollen die Anmeldung übernimmt. Danach laufen alle Tests aller Ebenen als Regressionstest; sie zeigen, was die Änderung kaputt macht, und ein Systemtest zeigt, dass er zu wenig prüft. Ausblick: Keycloak und OAuth2.
Übungen zu System- und Abnahmetest im Mitfahr-Backend: Du ordnest Prüfungen den Testebenen zu, liest einen Testbericht und triffst eine Abnahmeentscheidung, schreibst Abnahmetests mit RestTestClient für das Einstellen und Zurückziehen von Mitfahrgesuchen, findest heraus, warum ein Test nach zwei Wochen rot wird, und gibst ein zweites Frontend per CORS frei.
Bisher hat jeder Test nur einen Ausschnitt der Anwendung gestartet. Jetzt läuft das Mitfahr-Backend vollständig mit Tomcat und Datenbank, und RestTestClient schickt echte HTTP-Anfragen. Ein Systemtest prüft jede Antwort gegen den API-Vertrag openapi.yaml, ein Abnahmetest jedes Abnahmekriterium der User Stories aus Artikel 01. Beide finden je eine echte Lücke. Dazu kommen ein Abnahmeprotokoll, CORS für Browser-Frontends und eine eigene Stufe in der Pipeline.
Übungen zum Integrationstest der Web-Schicht im Mitfahr-Backend: Du ordnest zu, was @WebMvcTest startet, liest einen Controller-Test, schreibst Tests für das Einstellen von Mitfahrgesuchen und ihre Fehlerfälle, findest heraus, warum ein Test ohne @WebMvcTest mit „Request failed unexpectedly“ scheitert, und bewertest, was ein Test mit Mocks wirklich beweist.
Bisher prüfen nur .http-Dateien von Hand, ob die Controller richtig antworten. Jetzt übernimmt das ein Integrationstest der Web-Schicht: @WebMvcTest startet nur den Web-Teil von Spring, @MockitoBean ersetzt den Service durch einen Mock, und MockMvcTester schickt Anfragen ohne echten Server. Damit lassen sich Statuscodes, Header, JSON und alle Fehlerfälle aus Artikel 09 mit Problem Details automatisch prüfen. Unterwegs zeigen zwei Stolpersteine, was ein Testausschnitt (Slice) weglässt.
Seit Artikel 08 greifen die Fachregeln, aber jeder Verstoß endet als 500 Internal Server Error. Jetzt bekommt jede fachliche Ausnahme den Statuscode aus dem Vertrag: 404, 409 oder 422, beschrieben als Problem Details nach RFC 9457. Eine zentrale Klasse mit @RestControllerAdvice übernimmt das für alle Controller, auch für Vertragsverstöße (400). Dazu kommen die restlichen Endpunkte (Angebot ändern und absagen, Buchungen eines Angebots, Flurmonitor) und eigene Mapper-Klassen für die Umwandlung zwischen Entities und Vertragsmodellen.
