Übungsaufgaben zu Abnahmetest und Kanban-Metriken in der Desktop-App des Mitfahrlabors: Kennzahlen des Flusses zuordnen und berechnen, ein Cumulative Flow Diagram des Übungsteams lesen, den Abnahmetest für die Gesuche-Ansicht mit JUnit-Tags schreiben und im Service Delivery Review aus Kennzahlen Maßnahmen ableiten.
Ob die fertige Verwaltungssicht der Desktop-App tut, was Andrea Wolf und Thomas Becker brauchen, zeigt erst die Abnahme gegen die Akzeptanzkriterien. Du machst die Kriterien mit JUnit-Tags und Anzeigenamen zu einem eigenen Abnahmetest und hältst das Ergebnis in einem Abnahmeprotokoll fest. Danach misst das Team den Fluss: Durchlaufzeit, Lieferzeit ab Zusage, Durchsatz, WIP und das Cumulative Flow Diagram. Im Service Delivery Review leitet es daraus neue Regeln ab.
Übungsaufgaben zum Paketieren der Desktop-App des Mitfahrlabors: Begriffe rund um Laufzeitabbild und Installer zuordnen, die Build-Konfiguration für die Gesuche-App ergänzen, einen Pipeline-Job schreiben, der das Paket als Artefakt ablegt, und Paketierungsfehler anhand ihrer Symptome beheben.
Das Sekretariat soll die Desktop-App installieren können, ohne vorher Java einzurichten. Du baust mit jlink ein eigenes, verkleinertes Java nur aus den Modulen, die die App braucht, und machst daraus mit jpackage einen Installer: MSI für Windows, DEB für Linux. Beides läuft als Aufgabe in Gradle oder Maven, die Pipeline legt das Paket als Artefakt ab. Unterwegs findet die Abnahme einen typischen Paketierungsfehler, und am Ende steht, was jpackage nicht kann: Signatur und automatische Updates.
Übungsaufgaben zu GUI-Tests mit TestFX in der Desktop-App des Mitfahrlabors: Matcher und Queries passend auswählen und Testergebnisse vorhersagen, GUI-Tests für den Dialog „Mitfahrgesuch eintragen“ und die Gesuche-Ansicht schreiben und drei Fehler beheben, bei denen GUI-Tests nur in der Pipeline oder nur im Verbund rot sind.
Bisher prüfen die Tests der Desktop-App ViewModels, REST-Aufrufe und das Laden der Fenster, aber niemand klickt. Mit TestFX steuert ein Robot die Oberfläche wie ein Mensch: Er wählt eine Tabellenzeile, tippt in Textfelder und klickt Buttons; Matcher prüfen, was danach im Fenster steht. Du schreibst GUI-Tests für die Verwaltung und den Weg aus dem Hauptfenster, lässt sie mit Monocle ohne Bildschirm in der Pipeline laufen, grenzt sie von ViewModel-Tests ab und vergleichst TestFX mit Selenium und Playwright.
Übungen zur Verwaltungssicht der JavaFX-Desktop-App: Du wählst zu Fragen über Mitfahrgesuche den passenden Diagrammtyp, erweiterst den OpenAPI-Vertrag um eine Auswertung der Gesuche, bereitest die Gesuche als Daten für PieChart und BarChart auf und bewertest, was zwei Expedite-Tickets auf dem Kanban-Board bewirkt haben.
Die Desktop-App bekommt eine eigene Verwaltungssicht für Konten mit der Rolle ORGA: Haltepunkte in einer Tabelle anzeigen, anlegen und ändern, dazu die Auslastung je Haltepunkt als Balken- und Kreisdiagramm mit JavaFX Charts. Mittendrin kommt ein Expedite-Ticket: Ein Treffpunkt ist ab Montag gesperrt, und der Vertrag der REST-API kennt noch keinen Endpunkt zum Ändern. Du erweiterst openapi.yaml zuerst (Contract-First), prüfst den neuen Endpunkt gegen WireMock und siehst, was das Expedite-Ticket auf dem Kanban-Board und bei der Durchlaufzeit bewirkt.
Übungen zur Anmeldung der JavaFX-Desktop-App über Keycloak: Du ordnest die Schritte des Authorization Code Flow mit PKCE und ordnest Werte und Tokens zu, steuerst das Gesuche-Fenster nach Rolle, schreibst einen Token-Speicher, der rechtzeitig erneuert, und findest die Ursachen von Redirect- und Token-Fehlern anhand ihrer Meldungen.
Das siebte Ticket der Desktop-App: Statt ein Token von Hand zu setzen, meldet sich die JavaFX-App selbst bei Keycloak an. Als native App ist sie ein öffentlicher Client ohne Geheimnis. Sie öffnet die Anmeldeseite im Systembrowser, nimmt den Rückruf mit einem kleinen HTTP-Server auf 127.0.0.1 entgegen und tauscht den Code mit PKCE gegen Tokens. Das Access Token erneuert sie rechtzeitig mit dem Refresh Token, und die Rollen aus dem ID Token entscheiden, welche Buttons die Oberfläche zeigt.
Übungen zu Formularen und Dialogen in der JavaFX-Desktop-App: Du ordnest Steuerelemente und Arten des Alert zu und sagst vorher, was ein Eingabefilter aus einer Tippfolge macht, baust ein geprüftes Formular für Mitfahrgesuche als ViewModel mit Tests und einen eigenen Dialog dazu und findest vier Fehler in einem Formular anhand ihrer Symptome.
Das sechste Ticket der Desktop-App: Fahrer*innen legen ein Fahrtangebot über einen eigenen Dialog an und sagen ein Angebot nach einer Rückfrage ab. Du wählst für jede Eingabe das passende Steuerelement (ComboBox, DatePicker, Spinner, TextField mit TextFormatter), prüfst die Eingaben im ViewModel, zeigst Fehler direkt am Feld und baust einen Dialog, der nur mit gültigen Eingaben ein Ergebnis liefert. Ein Alert fragt vor dem Absagen nach. Auf dem Board teilt das Team ein zu großes Ticket auf.
Übungen zur TableView in der JavaFX-Desktop-App: Du ordnest CellValueFactory, CellFactory, Filter und Sortierung zu und sagst vorher, was beim Klick auf einen Spaltenkopf passiert, baust die Mitfahrgesuche als Tabelle mit Zellen und Sortierung, ergänzt einen Filter mit Notizsuche samt Tests und wertest die Durchlaufzeiten eines Kanban-Boards aus.
Das fünfte Ticket der Desktop-App: Zu jedem Fahrtangebot zeigt eine TableView die Buchungen. Du legst Spalten an, bestimmst mit der CellValueFactory, welcher Wert in eine Spalte kommt, und mit der CellFactory, wie die Zelle ihn zeigt. FilteredList und SortedList liefern die gefilterten Zeilen, und ein Klick auf den Spaltenkopf sortiert sie. Offene Anfragen bestätigst oder lehnst Du ab, die App schreibt dabei zum ersten Mal ins Backend. Zum Schluss misst das Team mit der Durchlaufzeit, wie schnell Tickets über das Board fließen.
Übungen zum Anbinden des Backends in der JavaFX-Desktop-App: Du ordnest Arbeiten dem JavaFX Application Thread oder einem Hintergrund-Thread zu und sagst die Reihenfolge von Ausgaben voraus, lädst die Mitfahrgesuche mit einem Task im Hintergrund, testest einen REST-Client für die Gesuche mit WireMock und findest heraus, warum eine Oberfläche einfriert und warum der erste Reparaturversuch neue Fehler bringt.
Das vierte Ticket der Desktop-App: Die Angebotsliste lädt die echten Angebote aus der REST-API des Backends. Du erzeugst einen Java-Client aus der openapi.yaml, lernst die Regeln des JavaFX Application Thread kennen und lädst die Daten mit Task im Hintergrund, damit die Oberfläche bedienbar bleibt. Fehler des Backends kommen als Problem Details an und erscheinen als Dialog. Zum Schluss prüft ein Integrationstest den Client gegen WireMock statt gegen das echte Backend.
Übungen zu Properties, Bindings und MVVM in JavaFX: Du sagst das Verhalten von uni- und bidirektionalen Bindings und Listenern voraus, schreibst ein ViewModel für die Mitfahrgesuche mit JUnit-Tests ohne Fenster, bindest die Gesuche-Maske daran und findest ein Speicherleck, eine Endlosschleife und zwei weitere Binding-Fehler anhand ihrer Symptome.
Das dritte Ticket der Desktop-App: Die Angebotsliste bekommt ein ViewModel. Du lernst Properties als beobachtbare Werte kennen, verbindest sie mit uni- und bidirektionalen Bindings, leitest Werte mit Bindings.createStringBinding ab und filterst und sortierst mit ObservableList, FilteredList und SortedList. Das Entwurfsmuster MVVM trennt View, ViewModel und Model, sodass sich die Logik ohne Fenster mit JUnit testen lässt. Zum Schluss geht es um Speicherlecks und Endlosschleifen, die Listener und Bindings verursachen können.
Bevor die erste Zeile JavaFX entsteht, richtet das Team ein Kanban-Board ein: Aus den Wünschen von Fahrer*innen und Verwaltung werden Tickets mit Akzeptanzkriterien, jede Spalte bekommt eine Regel für den Eintritt und ein WIP-Limit, und wer frei ist, zieht sich die nächste Arbeit. Serviceklassen regeln, was schneller gehen darf. Zum Schluss vergleichst Du Kanban mit Scrum und ziehst das erste Ticket.
Gradle baut Java-Projekte über einen Graphen aus Tasks, der nur das ausführt, was sich geändert hat. Der Artikel richtet Gradle mit Wrapper ein, baut ein Hello-World-Projekt ganz ohne Abhängigkeiten, erklärt den Task-Graphen des Java-Plugins und zeigt an einem Spring-Boot-Dienst, wie Stilprüfung, Unit-Tests, eine eigene Suite für Integrationstests und die Abdeckungsprüfung in den Task check eingehängt werden.
Übungen zu FXML, Layout-Containern und JavaFX-CSS: Du ordnest Anordnungen dem passenden Layout-Container zu, beschreibst das Gesuche-Fenster der Desktop-App als FXML-Datei, verbindest es mit einem Controller und einem Stylesheet und findest Fehler in einer FXML-Datei anhand der Meldungen.
Das zweite Ticket der Desktop-App: Der Aufbau des Hauptfensters wandert aus dem Java-Code in eine FXML-Datei. Du ordnest die Oberfläche mit den Layout-Containern BorderPane, HBox, VBox und GridPane, verbindest sie über fx:id, @FXML und onAction mit einem Controller, lernst den Scene Builder als grafischen Editor kennen und gestaltest das Fenster mit JavaFX-CSS. Zum Schluss geht es um die typischen Fehlermeldungen beim Laden von FXML.
Übungen zum JavaFX-Projekt der Desktop-App: Du bringst den Lebenszyklus einer Application in die richtige Reihenfolge, zerlegst ein Fenster in Stage, Scene und Nodes, baust ein Fenster mit Platzhalter für die Mitfahrgesuche samt Smoke-Test und behebst Startfehler rund um Modulsystem und fehlenden Bildschirm.
Das erste Ticket der Desktop-App: Du legst ein JavaFX-Projekt mit Gradle (oder Maven) an, bindest OpenJFX als Bibliothek ein und schreibst eine Application-Klasse, die ein Fenster öffnet. Dabei lernst Du den Lebenszyklus mit init(), start() und stop() kennen, unterscheidest Stage, Scene und Node, löst die typischen Startfehler rund um das Modulsystem und sicherst alles mit einem Smoke-Test ab, der auch ohne Bildschirm läuft.
Übungen zum Kanban-Projektstart der Desktop-App: Du ordnest Kanban-Begriffe zu, entscheidest an einem Board, ob ein Ticket gezogen werden darf, schreibst Tickets mit Akzeptanzkriterien und Serviceklasse für die Mitfahrgesuche, richtest dafür Spalten mit Regeln und WIP-Limits ein und findest den Engpass in einem Board, das schon drei Wochen läuft.
In zwölf Artikeln entsteht mit JavaFX eine Desktop-App für das Mitfahrlabor: Fahrer*innen verwalten ihre Angebote und Buchungen, die Verwaltung pflegt Haltepunkte und sieht die Auslastung. Die App spricht mit der REST-API des Spring-Boot-Backends, die Anmeldung läuft über Keycloak, und organisiert wird die Arbeit mit Kanban. Hier findest Du den Fahrplan, die Architektur, die Voraussetzungen und den Vergleich von Desktop- und Web-Oberflächen.
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.
