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