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