Ü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.
Übungen zur Service-Schicht im Mitfahr-Backend: Du erkennst die drei Arten der Dependency Injection, beurteilst Aussagen zu Mocks und Transaktionen, schreibst einen GesuchService mit Konstruktorinjektion und einer injizierten Uhr, testest ihn mit Mockito und findest heraus, warum ein zurückgezogenes Gesuch trotz grüner Tests offen bleibt und warum das Abdeckungs-Gate ein anderes Paket meldet als erwartet.
Bisher speichert der Controller Angebote direkt über die Repositories, und keine der Fachregeln aus Artikel 04 wird geprüft. Jetzt kommt eine Service-Schicht dazwischen: Spring setzt Controller, Services, Repositories und eine Uhr per Konstruktorinjektion zusammen, @Transactional macht aus jeder Buchungsänderung eine Transaktion, und Buchungen lassen sich endlich anfragen, bestätigen und stornieren. Getestet wird der Service mit Mockito ganz ohne Datenbank; ein Abdeckungs-Gate lässt den Build scheitern, wenn die Tests zu wenig prüfen.
Bisher stehen die Haltepunkte fest im Code, und neue Angebote verschwinden beim Neustart. Jetzt bekommt das Mitfahr-Backend eine Datenbank: Aus dem Fachmodell werden JPA-Entities mit Beziehungen, Spring Data erzeugt den Zugriff aus einem leeren Interface, Hibernate legt die Tabellen an, und eine data.sql füllt die H2-Datenbank beim Start mit den Daten des Szenarios. Wer Docker nutzt, startet dieselbe Anwendung mit MariaDB.
Übungen zur Qualitätssicherung im Build des Mitfahr-Backends: Du ordnest Werkzeuge und Pipeline-Begriffe zu, deutest Checkstyle-Meldungen zur Zeitfensterregel der Mitfahrgesuche, liest Anweisungs- und Zweigabdeckung aus einem JaCoCo-Bericht ab, ergänzt eine Regel gegen „magische Zahlen“, passt die GitLab-Pipeline an und zeigst, warum 100 % Abdeckung einen Fehler an der Grenze nicht findet.
Tests helfen nur, wenn sie auch laufen. Der Build des Mitfahrlabors bekommt drei Prüfwerkzeuge: Checkstyle prüft Regeln für den Code, Spotless sorgt für einheitliche Formatierung, JaCoCo misst die Testabdeckung. Alle hängen an der Sammelaufgabe check (Gradle) bzw. der Phase verify (Maven). Eine Pipeline in GitLab CI führt bei jedem Push die Stufen build, test, quality und package aus und zeigt Testergebnisse und Abdeckung im Merge Request.
Übungen zur Fachlogik im Mitfahr-Backend: Du bildest Äquivalenzklassen und Grenzwerte für einen Kostenbeitrag, ordnest JUnit-Zusicherungen zu, schreibst einen parametrisierten Test zur Einwilligung, setzt die Zeitfensterregel für Gesuche samt Tests um, testest die Statuswechsel eines Gesuchs vollständig und findest einen Rundungsfehler, den double verursacht.
Die Regeln, die der API-Vertrag nicht ausdrücken kann, kommen ins Paket domain: der Kostenbeitrag je Kilometer, die Einwilligung bei Minderjährigen und die erlaubten Wechsel des Buchungsstatus. Sie entstehen in reinem Java ohne Spring, mit BigDecimal, LocalDate, einem switch-Ausdruck und eigenen Exceptions. Mit Äquivalenzklassen und Grenzwerten findest Du die Testfälle und prüfst sie mit parametrisierten JUnit-Tests: die erste Testebene des V-Modells, der Komponententest.
Übungen zur Codegenerierung im Mitfahr-Backend: Du ordnest Angaben im Vertrag dem erzeugten Java-Code zu, sagst Statuscodes voraus, bestimmst die erzeugte Schnittstelle für die Gesuche, implementierst sie, entscheidest, welche Regeln Bean Validation prüft, findest Fehler anhand von Symptomen und beurteilst Contract First gegenüber Code First.
Der OpenAPI Generator macht aus dem API-Vertrag Java-Schnittstellen und Datenklassen. Du bindest ihn in Gradle oder Maven ein, lässt den Controller für die Haltepunkte die erzeugte Schnittstelle implementieren und siehst, wie die Regeln aus dem Vertrag als Bean Validation fehlerhafte Anfragen mit 400 abweisen. Weicht der Code vom Vertrag ab, merkt es der Compiler; ist der Vertrag fehlerhaft, bricht der Build ab.
Übungen zum Spring-Boot-Projekt des Mitfahr-Backends: Du ordnest Annotationen und Dateien zu, schreibst einen Controller für Mitfahrgesuche mit Record und Pfadvariable, sagst Antworten auf Anfragen voraus, findest Fehler in einem Controller anhand ihrer Symptome und ergänzt einen Filter über einen Query-Parameter.
Mit dem Spring Initializr entsteht das Projekt für das Mitfahrlabor-Backend. Du lernst die Projektstruktur, den Build mit Gradle oder Maven und die Startklasse kennen, schreibst den ersten REST-Controller für die Haltepunkte von Hand, rufst ihn mit dem Browser, einer .http-Datei oder der Shell auf und lässt den ersten Test laufen: einen Smoke-Test, der prüft, ob die Anwendung überhaupt startet.
Das MVP der Mitfahr-App kennt nur Angebote. In diesen Übungen planst Du die Ressource „Gesuch“ für alle, die kein Auto haben: Du ordnest Entwurf und Test im V-Modell zu, wählst Methoden und Statuscodes, schreibst User Story und Abnahmekriterien, entwirfst Endpunkte und Schemas im OpenAPI-Vertrag, findest Fehler in einem Vertragsausschnitt und zeichnest die Zustände eines Gesuchs.
Bevor die erste Zeile Java entsteht, wird geplant: Aus dem Auftrag werden User Stories mit Abnahmekriterien, aus den Fachregeln ein Fachmodell mit Zustandsdiagramm, aus der Architektur ein Schichtenmodell und aus allem zusammen ein API-Vertrag im Format OpenAPI. Damit ist die linke Seite des V-Modells für das Mitfahrlabor-Backend vollständig, und jede spätere Testebene weiß, wogegen sie prüft.
Ein zentrales Konzept der objektorientierten Programmierung (OOP) ist die Polymorphie: die Vielgestalt von Objekten. Es ermöglicht über Instanztypen das Verhalten eines Objekts festzulegen, während der Typ der Referenz festlegt, welche Member erreichbar sind. Welche Implementierung läuft, entscheidet sich erst zur Laufzeit (späte Bindung). Der Artikel zeigt außerdem, wie Du Polymorphie im UML-Klassendiagramm modellierst, Fallunterscheidungen damit ersetzt und typische Fehler vermeidest.
Für die Zustandsübergänge (Transitionen) unseres Command-Line-Interface-Programms müssen noch Effekte (Aktionen) erstellt werden. Dabei müssen wir eine ganze Menge umbauen, um für Typsicherheit zu sorgen.
Am Beispiel eines Command-Line-Interfaces wird das State-Pattern beispielhaft in Java implementiert – nachdem die Grundstruktur und die Zustands-ENUMS in den vorigen Teilen erstellt wurden, geht es jetzt um die objektorientierte Realisierung der Transitionen und Menüstruktur.
Am Beispiel eines Command-Line-Interfaces wird das State-Pattern beispielhaft in Java implementiert. In diesem Teil geht es um das Instanzenmanagement der einzelnen Zustandsklassen mit Hilfe von Singletons/Enums.
Am Beispiel eines Programms mit Kommandozeilenmenü wird das State-Pattern beispielhaft in Java implementiert: Eine Fingerübung, um das Pattern, Transitionen und die Elemente des UML-Zustandsdiagramms zu verinnerlichen. Im ersten Teil geht es zunächst um den Aufbau des Patterns selbst und die Grundstruktur.
Ohne Test-Duplikate ist es oft nicht möglich, ein einzelnes Modul zu testen. Abhängigkeiten machen sonst jeden Unit-Test zum Integrationstest. Wir lernen Mocks und Stubs kennen, und dabei – wie aus Versehen – den Unterschied zwischen zustandsbasierten und verhaltensbasierten Unittests. Am Beispiel Mockito/jUnit…
Mit dem Buildtool Maven kann der Erstellungsprozess von Software automatisiert werden: Kompilieren, Testen, Packen und Veröffentlichen kann nach einem vorkonfigurietem Muster wiederholbar ablaufen
Das Maven-Projekt wird so konfiguriert, dass nach jedem Unit-Test-Durchlauf die Überdeckungstestmetriken gespeichert und als Report aufbereitet werden.
Es werden Unit-Tests für den REST-Controller erstellt. Dazu wird eine gemockte Umgebung konfiguriert. Das Testframework von Spring mit seinen zahllosen Klassen wird vorgestellt.
Es wird die eigentliche REST-API für unsere Adressen erstellt: Methoden für PUT, GET, POST und DELETE. Die API wird per PowerShell oder Bash aufgerufen, um sie auszuprobieren.
Die zentralen CRUD-Funktionen des Repositories werden getestet. Dazu wird die given-when-then-Methodik verwendet und in jUnit jeweils Testmethoden implementiert.
Es werden die Abhängigkeiten für ein Model angefügt, eine Modelklasse erstellt und annotiert. Die OOP-Hintergründe für Repositories werden kurz an UML-Klassendiagrammen erläutert
Das UML-Klassendiagramm ist die zentrale Modellierungssprache der objektorientierten Programmierung (OOP). Dieser Einstiegsartikel zeigt den Aufbau einer Klasse, die Darstellung ihrer Member (Attribute und Methoden), Überladung sowie Instanz- und Klassenattribute und -methoden. Außerdem geht es um die vollständige Schreibweise von Attributen und Methoden und darum, wie Du aus einem Anforderungstext ein Klassendiagramm entwickelst.
Wie erstelle ich leaf nodes und branch nodes mit JavaFX? Welche habe ich zur Auswahl? Und wie versehe ich Widgets – wie zum Beispiel Buttons mit Events?
Was passiert unter der Oberfläche in JavaFX? Was ist eine Scene, ein Root Node, ein branch node und ein Leaf node? Der Artikel ist Teil eines JavaFX-Tutorials.
„Hello World“ mit Java FX und Analyse der beteiligten Klassen, Objekte und Methoden. Artikel ist Teil eines JavaFX-Tutorials.
Erstellung eines JavaFX-Projekts, Aufbau der Maven-Konfiguration pom.xml und Starten des Programms (auch mit Maven). Artikel ist Teil eines JavaFX-Tutorials.
