Sprint Planning

GUI-Tests mit Selenium und Page Objects: der Flurmonitor im echten Browser

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.

Konfiguration, Formatierung und Barrierefreiheit: Sprint 2 macht den Flurmonitor alltagstauglich

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.

Thymeleaf ins Backend einbinden: Controller, Model und das erste Template für den Flurmonitor

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.