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.
Ü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.
