Seminar NestJS – Testing und Qualitätssicherung

Eine große Testmenge ist nicht automatisch eine gute Teststrategie. Wert entsteht, wenn Tests konkrete Risiken abdecken, schnelle Rückmeldung liefern und in reproduzierbaren Umgebungen stabil bleiben.

Der Kurs ordnet NestJS-spezifische Testwerkzeuge in eine risikobasierte Testarchitektur ein. Fachlogik, Dependency Injection, Datenbankzugriff, Sicherheitsgrenzen und HTTP-Verträge werden auf unterschiedlichen Ebenen geprüft.

Inhaltsübersicht

• Lernziele
• Teststrategie und Testpyramide
• Unit- und Modultests mit TestingModule
• Integrationstests für Datenbank und Infrastruktur
• End-to-End- und Contract-Tests
• Stabilität und CI-Integration
• Praxisprojekt: Testarchitektur für eine geschützte API
• Prüfpunkte und typische Fehler

Lernziele

• Risiken, Testebenen und Verantwortlichkeiten in einer Testmatrix zuordnen.
• Provider, Pipes, Guards, Interceptors und Controller mit dem TestingModule prüfen.
• Datenbank- und Infrastrukturtests mit realen Abhängigkeiten reproduzierbar ausführen.
• End-to-End-Tests für vollständige HTTP- und Authentifizierungsabläufe implementieren.
• Contract-Tests für OpenAPI, Nachrichten und externe Schnittstellen ergänzen.
• Testdaten, Parallelität, Flakiness, Abdeckung und CI-Gates kontrollieren.

Teststrategie und Testpyramide

Die Teststrategie beginnt mit Fehlerauswirkungen und Änderungswahrscheinlichkeit. Daraus folgt, welche Regeln isoliert, welche Integrationen real und welche Nutzerabläufe vollständig geprüft werden.

1. Fachregeln, API-Verträge, Sicherheitsgrenzen, Datenintegrität und Betriebsrisiken inventarisieren.
2. Unit-, Modul-, Integrations-, Contract- und End-to-End-Tests klar abgrenzen.
3. Schnelle Tests häufig und teure Systemtests gezielt ausführen.
4. Testfälle nach beobachtbarem Verhalten strukturieren.
5. Fehlerszenarien und negative Pfade gleichwertig zu Erfolgsfällen behandeln.
6. Abdeckung als Hinweis und nicht als alleinige Qualitätskennzahl verwenden.

Entscheidungskriterien und Hinweise

• Jede Testebene besitzt eine eindeutige Aussage und vermeidet unnötige Duplikation.
• Kritische fachliche Risiken erhalten mehrere komplementäre Prüfungen.

Unit- und Modultests mit TestingModule

NestJS-Komposition wird in kleinen Testmodulen aufgebaut. Abhängigkeiten werden nur dort ersetzt, wo die Testaussage sonst unkontrollierbar wäre.

1. Provider mit realistischen Eingaben und expliziten Abhängigkeits-Tokens konfigurieren.
2. Repository- oder Client-Abhängigkeit durch fokussiertes Test Double ersetzen.
3. Erfolgs-, Validierungs-, Konflikt- und Fehlerpfade des Fachservices prüfen.
4. Pipes und Guards mit repräsentativem Execution Context testen.
5. Controller auf Transportmapping und delegiertes Verhalten prüfen.
6. Interceptors und Exception Filter anhand ihres externen Vertrags testen.
7. Testfabriken ohne versteckte globale Zustände aufbauen.

Entscheidungskriterien und Hinweise

• Mocks bilden nur die für den Test notwendige Schnittstelle ab.
• Controller-Tests wiederholen nicht vollständig die Fachservice-Tests.

Integrationstests für Datenbank und Infrastruktur

Mocks können SQL, Migrationen, Constraints oder Transaktionsfehler nicht zuverlässig abbilden. Für diese Risiken wird eine reale, isolierte Testabhängigkeit verwendet.

1. Testdatenbank mit derselben Hauptversion und denselben Migrationen wie die Zielumgebung starten.
2. Schema pro Testlauf reproduzierbar aufbauen und Versionsstand prüfen.
3. Constraints, Transaktionen, Konkurrenz und Fehlerübersetzung testen.
4. Deterministische Testdatenfabriken mit fachlich gültigen Standardwerten verwenden.
5. Isolation durch Rollback, Schema oder getrennte Datenbankinstanzen sicherstellen.
6. Externe Adapter mit kontrollierten Gegenstellen oder Protokollsimulationen testen.

Entscheidungskriterien und Hinweise

• Datenbanktests laufen gegen reale Migrationen und nicht gegen ein abweichendes Testschema.
• Testdaten sind minimal, verständlich und unabhängig.

End-to-End- und Contract-Tests

End-to-End-Tests starten die reale Anwendung und prüfen vollständige HTTP-Abläufe. Die Zahl bleibt begrenzt; ausgewählt werden kritische Nutzerpfade und Integrationsrisiken.

1. Anwendung mit Testkonfiguration und realer Datenbank initialisieren.
2. Testidentitäten, Mandanten und Ausgangsdaten kontrolliert erzeugen.
3. Erfolgsablauf über mehrere Requests und Zustandsänderungen prüfen.
4. Validierung, Authentifizierung, Autorisierung und Konfliktfälle testen.
5. Statuscodes, Header, Antwortschemata und Fehlervertrag verifizieren.
6. OpenAPI-Schema und repräsentative Antworten auf Kompatibilität prüfen.
7. Nach jedem Test Datenzustand und unerwartete Seiteneffekte kontrollieren.

Entscheidungskriterien und Hinweise

• Negative Sicherheitsfälle prüfen Datenabfluss und Seiteneffekte.
• Contract-Tests schützen den externen Vertrag, nicht interne Implementierungsdetails.

Stabilität und CI-Integration

Flaky Tests untergraben Vertrauen. Ursachen liegen meist in Zeit, Zufall, gemeinsamem Zustand, externen Abhängigkeiten oder unkontrollierter Parallelität.

1. Zeit und Zufall injizierbar machen und feste Testwerte verwenden.
2. Asynchrone Operationen vollständig erwarten und offene Handles erkennen.
3. Parallelität nur bei nachgewiesener Datenisolation aktivieren.
4. Fehlerhafte Tests nicht pauschal wiederholen, sondern Ursache sichtbar machen.
5. Pipeline in schnelle Prüfungen, Integration und End-to-End-Stufen gliedern.
6. Testberichte, Logs und relevante Artefakte bei Fehlern sichern.
7. Release-Gates für Build, Typprüfung, Migration, Sicherheit und Verträge definieren.

Entscheidungskriterien und Hinweise

• Automatische Wiederholung ist höchstens Diagnosehilfe und keine dauerhafte Lösung.
• Pipeline-Gates sind schnell genug für regelmäßige Ausführung und streng genug für Freigaben.

Praxisprojekt: Testarchitektur für eine geschützte API

Eine bestehende API besitzt Fachservice, Datenzugriff, Authentifizierung und mehrere HTTP-Abläufe. Die Ausgangstests sind langsam, stark gemockt und teilweise instabil.

Die Tests werden nach Risiko und Ebene neu geordnet. Reale Datenbankmigrationen, negative Berechtigungsfälle und ein vollständiger Kernablauf bilden den Abnahmeprüfpfad.

1. Risiken erfassen und Testmatrix für Fachlogik, Datenbank, Sicherheit und API-Vertrag erstellen.
2. Unit-Tests für Fachservice und Policy-Entscheidungen aufbauen.
3. Modultests für Pipes, Guards und Fehlerfilter ergänzen.
4. Reale Testdatenbank migrieren und Repository-Integration prüfen.
5. End-to-End-Tests für Kernablauf und verweigerte Zugriffe implementieren.
6. OpenAPI- und Antwortverträge automatisiert vergleichen.
7. Flaky Test analysieren und Zeit- oder Zustandsabhängigkeit beseitigen.
8. Teststufen und Qualitäts-Gates in einer CI-Pipeline ordnen.

Prüfpunkte und typische Fehler

• Mocks werden nur für klar kontrollierte Grenzen verwendet.
• Tests prüfen beobachtbares Verhalten.
• Datenbanktests führen reale Migrationen und Constraints aus.
• End-to-End-Tests decken negative Sicherheits- und Validierungsfälle ab.
• Parallelität wird erst nach gesicherter Isolation aktiviert.
• Flaky Tests werden analysiert und nicht dauerhaft kaschiert.