Kernel-Teststrategie

1) Grundsätze

Pyramiden- und Trophäenbilanz. Basis - schnelle Modul- und Vertragstests; oben - Komponenten und Integration; an der Spitze ist die minimale, aber wertvolle Schicht e2e.
Shift-left. Je früher wir einen Defekt auffangen (Linter, statische Analyse, eigenschaftsbasiert), desto günstiger.
Deterministic by design. Wir verwalten Zeit, Netzwerk, Zufall und externe Abhängigkeiten.
Die Ökonomie der Qualität. Jeder Test ist eine „Versicherung“: Ziel ist es, die Gesamtkosten (Mängel + Begleitung der Tests) zu minimieren.
Risikoorientiert. Die Abdeckung konzentriert sich auf geschäftliche Invarianten und Protokolle (Verträge, Idempotenz, Konsistenz).

2) Testebenen und Verantwortungsbereiche

2. 1 Einheit (modular)

Überprüfen Sie die reine Logik ohne I/O.
Wir benetzen nur Grenzen (Port/Adapter), verwenden Fabriken für Daten.
Schnell (≤50 -100 ms/Test), parallel.

2. 2 Vertrag (Lieferant ↔ Verbraucher)

Erfassen Sie API-Verträge (HTTP/gRPC/event) zwischen den Diensten.
Wir verwenden einen consumer-driven Ansatz: Verträge werden im VCS gespeichert, im CI des Lieferanten geprüft.
Reduzieren Sie die Fragilität der Integration e2e.

2. 3 Komponenten (über Modul, mit echtem Speicher)

Wir starten einen Teil des Dienstes mit einer echten DB/Cache im Container (Testcontainer).
Wir validieren Schemamigrationen, Indizes, Transaktionen, Sperren.

2. 4 Integration/System (End-to-End-Pfade zwischen den Diensten)

Wir heben eine Reihe von Diensten in einer isolierten Umgebung an.
Wir überprüfen End-to-End-Invarianten: Transaktionalität, Retrays, Idempotenz, Fehlerbehandlung.

2. 5 E2E (minimale „wertvolle“ Schicht)

Die realen Protokolle und die Umgebung „wie in proda“, aber der beschränkte Drehbuchsatz: die Bezahlung → die Bestätigung → die Verbuchung; Registrierung → Verifizierung → Anmeldung.
Wir verwenden für die Freigabe von Releases und die Regression von Hochrisiko-Fich.

3) Testbare Architektur

Anschlüsse/Adapter (Hexagonal). Der Business-Kernel kennt HTTP/SQL nicht; Abhängigkeiten werden über Schnittstellen implementiert.
Zeitinjektion/Random. 'Clock', 'Random' - Abhängigkeiten; in Tests zu erfassen.
Konfigurierbare I/O-Abstraktion. Warteschlangen, DB, KMS - über Schnittstellen mit Testimplementierungen.
Funktionale Invarianten. Wir formulieren explizit Postbedingungen und Prädikate - sie sind einfacher zu testen und zu überwachen.

4) Daten für Tests

Fabriken/Bilder statt statischer JSON-Fixturen: weniger Fragilität.
Idempotente Sids und Reset-Hook-DB vor dem Test (Migrations → Truncate → Seed).
Fallkataloge: „Normen“, „Kanten“, „Fehler“, „Chaos“.
Synthetik statt echter PD: Generatoren, Maskierung, Datenschutzprofile.

5) Wettbewerb und Idempotenz

Race-Tests: Wettbewerbsrekorde/Reserven/Blockaden.
Idempotente Schlüssel überprüfen (z.B.'(operation, external_id)'): Wiederholte Aufrufe ändern den Status nicht.
Retrays und Timeouts: Wir garantieren die Korrektheit bei temporären Fehlern.

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6) Zeit, Timeouts, Zeitzonen

Alle gespeicherten Zeiten sind UTC; in Tests verwenden wir 'FixedClock'.
Wir testen DST-Fälle (Takes/Überspringen von Uhren), Fenster des „lokalen Tages“.
Wir überprüfen die Timeouts mit einer monotonen Uhr; Wir simulieren NTP-Jitter.

7) Nachhaltigkeit und Chaos

Fehlerbehebung: Netzwerkfehler, 5xx, Verzögerungen, partielle Degradation (Cache nicht verfügbar).
Chaos-Tests in der Pre-Prod-Umgebung: Knoten abschalten, Warteschlangen überlasten, BGP/Anycast-Breaks (Emulation).
Fallback-Richtlinien und UX-Degradierung: Tests müssen eine korrekte „graceful degradation“ bestätigen.

8) Produktivität

Mikro-Benchmarks für kritische Algorithmen (mit CPU/Alloc-Fixierung).
Lastprofile: baseline (p50/p95), stress (peak), verlängert (soak) für Speicherlecks.
Regress Gates: Build scheitert, wenn p95 Latenzen schlechter sind als baseline> X%.

9) Sicherheit und Compliance

SAST/Lint: Suche nach Schwachstellen/Anti-Pattern.
DAST/IAST: Basisszenarien am Stand (XSS/SQLi/SSRF-Proben).
Secrets-Scan: Keine Schlüssel/Passwörter im Code und Artefakten.
Privacy-Tests: keine PD in Logs/Traces, Einhaltung von „Consent Management“, Anonymisierungsprofile für Uploads.

10) Qualitätsmetriken und SLO

Test-Pass-Rate und Flaky-Index (Anzahl der instabilen Tests/Woche).

• 90-100% für kritische Kernelmodule,
• 70-80% für die Peripherie (mit Fokus auf Invarianten).
• Release-Risiko-Score: Aggregat: Änderungen in kritischen Dateien × fallende Benchmarks × neue Flaky.
• Fehlerhaftes Budget: Bündel von Prod-SLO (Aptime/Bugs) mit Experimenten und Release-Frequenz.

11) CI/CD und Gates

1. Lint/Format/TypeCheck

2. Unit + Property-based

3. Contract provider/consumer

4. Component (Testcontainers)

5. Integration + Perf smoke

6. Security (SAST/Secrets)

7. Build/Package + SBOM

8. Deploy to pre-prod + e2e + chaos smoke

Gates: Stopp bei sinkenden Verträgen, steigender Latenz, neuen kritischen Schwachstellen.

Cache und Sharding: Wir beschleunigen die Pipeline durch Parallelität und inkrementelle Durchläufe (durch geänderte Module).

12) Flaky-Tests: Erkennung und Behandlung

Autopovator + Quorum (2/3 Läufe).
Flaki-Muster-Detektor: Abhängigkeit von Zeit/Random/impliziten Erwartungen.
Quarantäne mit SLA: Der Test blockiert keine Freigaben, sondern muss in N Tagen korrigiert/umgeschrieben werden.
Null Toleranz gegenüber Flaka im „Kern“ des kritischen Pfades.

13) Eigentumsbasierte, Mutations- und Phasentests

Eigenschaftsbasiert: Wir formulieren Eigenschaften (Kommutativität, Idempotenz, Monotonie), Grenzdatengeneratoren.
Mutationstests: Wir messen die „Stärke“ der Tests (ob sie die eingeführten Mutationen abtöten).
Fuzzing: Protokolle/Parser/Formate (JSON, Protobuf, CSV), insbesondere an Sicherheitsgrenzen.

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14) Beobachtbarkeit und Zusammenhang mit Tests

Testtraces (trace-id in logs): bequem in pre-prod replizieren.
Metriken-Snap-Shots im Performance-Lauf - speichern wir als Artefakt.
Logkontrolle: keine empfindlichen Felder, Loggröße innerhalb SLO.

15) Dokumentation und Verfahren

Test Handbook: Wo welche Tests laufen, wie man Fabriken schreibt, wie man Verträge aktualisiert.
Runbooks: Replikate des Vorfalls, schnelle Diagnose, Release-Rollback.
Invariantenkatalog: Liste der Systemgarantien und Verweise auf relevante Tests/Alerts.

16) Checkliste des Architekten

1. Kernel-Invarianten und kritische Pfade beschrieben?
2. Gibt es eine Matrix von Testniveaus und deren SLO (Time, Stability)?
3. Werden Verträge im CI beim Lieferanten und Verbraucher versioniert und validiert?
4. Zeit/Rand/Netzwerk in Tests kontrollierbar (FixedClock, Fault-Injector)?
5. Testcontainer/isolierte DB konfiguriert, Migrationen geprüft?
6. Gibt es Performance-Baslines und ein Regressionstor?
7. Enthalten sind SAST/Secrets-Scan und Privacy-Check-Logs?
8. Werden Flaky-Aufzeichnungen geführt und gibt es einen SLA zur Korrektur?
9. Ist die Verknüpfung der Tests mit dem Prod-SLO und dem fehlerhaften Budget transparent gestaltet?
10. Sind das runbook ™ und der Invariantenkatalog dokumentiert?

Schluss

Die Kernel-Teststrategie ist keine Werkzeugliste, sondern eine architektonische Fähigkeit: ein testbares Design, eine strenge Hierarchie von Ebenen, verwaltete Daten, Fehlertoleranz und Metriken, die in CI/CD eingebettet sind. Nach den beschriebenen Vorgehensweisen erhält das Team ein schnelles und zuverlässiges Feedback und die Releases werden vorhersehbar und sicher.