In zwölf Artikeln bekommt das Mitfahrlabor-Backend eine erste Oberfläche: einen Flurmonitor, dessen HTML-Seiten der Server selbst mit der Template-Engine Thymeleaf erzeugt. Das Team arbeitet dabei nach Scrum in drei Sprints und prüft den Monitor auf allen Testebenen bis zur Abnahme. Hier findest Du den Fahrplan, die Voraussetzungen und die Einordnung ins Backend.
Übungen zum Änderungsantrag „Anmeldung statt Nutzer-ID“ im Mitfahr-Backend: Du ordnest Anfragen den Statuscodes 401 und 403 zu, analysierst die Auswirkungen auf die Mitfahrgesuche, ergänzt die Regeln der SecurityFilterChain, lässt nur eigene Gesuche zurückziehen, testest den Controller mit @WithMockUser und bewertest HTTP Basic gegenüber OAuth2.
Das Mitfahr-Backend ist abgenommen, da kommt ein Änderungsantrag: Statt die Nutzer-ID im Body mitzuschicken, sollen sich alle anmelden. Der Artikel zeigt, wie eine Auswirkungsanalyse die betroffenen Teile findet, wie der API-Vertrag securitySchemes bekommt und wie Spring Security mit HTTP Basic, Passwort-Hashes und Rollen die Anmeldung übernimmt. Danach laufen alle Tests aller Ebenen als Regressionstest; sie zeigen, was die Änderung kaputt macht, und ein Systemtest zeigt, dass er zu wenig prüft. Ausblick: Keycloak und OAuth2.
Ü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.
Ü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 zu Abfragen und Integrationstests im Mitfahr-Backend: Du übersetzt Methodennamen in SQL, ordnest Aussagen zu @DataJpaTest ein, schreibst eine JPQL-Abfrage, die zu einer Abfahrtszeit die passenden Mitfahrgesuche findet, testest sie an den Grenzen des Zeitfensters und findest heraus, warum ein Test allein grün und in der Testsuite rot ist und warum ein anderer nur in der Pipeline mit MariaDB scheitert.
Die Repositories aus Artikel 06 können bisher nur, was sie von JpaRepository geerbt haben. Jetzt bekommen sie eigene Abfragen: aus dem Methodennamen abgeleitet oder mit @Query in JPQL geschrieben. Ob diese Abfragen das Richtige finden, prüfen Integrationstests mit @DataJpaTest gegen eine echte Datenbank: H2 beim täglichen Testlauf, MariaDB in der Pipeline. Nebenbei beantwortet GET /angebote endlich Suchanfragen.
Übungen zur Persistenz im Mitfahr-Backend: Du ordnest Java- und Datenbankbegriffe zu, liest das von Hibernate erzeugte SQL für die Tabelle der Mitfahrgesuche, schreibst die Entity Gesuch, ein Repository und die Startdaten in data.sql, deutest eine Fehlermeldung zum Fremdschlüssel, machst die Beziehung zwischen Nutzer und Gesuch in beide Richtungen navigierbar und zeigst, warum EnumType.ORDINAL gespeicherte Daten unbemerkt verfälscht.
Ü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.
Ü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.
Sechs Übungsaufgaben zur Leitungsdimensionierung – von Einflussgrößen und Verlegearten in einer Werkstatt über Betriebsstrom, Strombelastbarkeit mit Umrechnungsfaktoren, Leitungsschutzschalter und Spannungsfall einer Drehstromleitung, einen Planungsvorschlag für eine Servicetheke, die Zuleitung eines Kompressors, die Verluste beim ein- und dreiphasigen Anschluss eines Klimageräts und ein Klemmen-Messprotokoll bis zur Frage, ob sich ein größerer Querschnitt lohnt. Zu jeder Teilaufgabe lässt sich eine Beispiellösung einblenden.
Welcher Querschnitt reicht für eine neue Leitung, welcher Leitungsschutzschalter passt dazu, und kommt am Ende noch genug Spannung an? Der Artikel führt Schritt für Schritt durch Einflussgrößen, Betriebsstrom, Leitungstyp und Leitungsbezeichnung, Verlegeart, Strombelastbarkeit mit Umrechnungsfaktoren für Temperatur und Häufung, Überstromschutz und Abschaltbedingung sowie Spannungsfall mit Querschnitt und maximaler Leitungslänge. Zum Schluss geht es um Verlustleistung an Leitungen und Klemmstellen und darum, wann sich ein größerer Querschnitt lohnt.
Neun Übungsaufgaben zu Netzsystemen und Schutzeinrichtungen – vom Erkennen der Netzsysteme und dem Hausanschluss über Auswahl und Kennlinien von Leitungsschutzschaltern, Feinsicherungen mit Sicherungsanzeige, Motorschutz, Schutzklassen und Fehlerstrom-Schutzeinrichtungen und die Abschaltbedingung im TN-System bis zur Bestandsaufnahme einer Etagenverteilung mit PEN-Leiter, drei Beobachtungen zu Leitungsschutzschaltern in einer Fahrradwerkstatt, der RCD-Prüfung für Akku-Ladeschränke und einem neuen Abgang für einen Netzwerkschrank. Zu jeder Teilaufgabe lässt sich eine Beispiellösung einblenden.
Wie kommt die Energie vom Netz bis zur Steckdose, woran erkennst Du ein TN-, TT- oder IT-System, und warum gehört der PEN-Leiter nicht in die Nähe von Netzwerkschränken? Der Artikel erklärt Schritt für Schritt Hausanschluss, Netzsysteme und Leiterbezeichnungen, den Fehlerschutz im TN-System mit Schutzpotenzialausgleich, Leitungsschutzschalter mit Auslösekennlinien und Selektivität, Fehlerstrom-Schutzeinrichtungen und RCBO, Schutzklassen, Feinsicherungen mit Sicherungsanzeige sowie Motorschutzschalter und Motorschutzrelais.
Welche Leitung passt zu welchem Gerät, wie schließt Du Adern sicher an, und woher weißt Du, welche Buchse auf einen Stecker passt? Der Artikel erklärt Schritt für Schritt Leitungsbezeichnungen und Aderfarben, das Erneuern einer Netzanschlussleitung bei Schutzklasse I und II, die lötfreien Verbindungstechniken mit Aderendhülsen, das Verzinnen von Litzen, Flachbandleitungen und Kabelbäume, die Auswahl von Steckverbindern nach Herstellerangaben, Verbindungslisten und Blockschaltbilder, das Prüfen konfektionierter Leitungen und die Beschaltung einer Verteilerdose.
