Sanity Testing
Leichtgewichtige Prüfung kritischer Funktionen nach kleineren Änderungen, um grundlegende Stabilität sicherzustellen.
Klassifikation
- KomplexitätNiedrig
- AuswirkungTechnisch
- EntscheidungstypDesign
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Verlassen auf Sanity-Tests statt kompletter Regression führt zu unentdeckten Fehlern.
- Flaky oder unsaubere Tests erzeugen unnötige Rollbacks und Verzögerungen.
- Unzureichende Abdeckung kritischer Bereiche kann falsche Sicherheit suggerieren.
- Beschränke Tests auf wirklich kritische Funktionalität.
- Integriere Sanity-Tests früh in die Pipeline (pre-merge oder post-build).
- Automatisiere Auswertung und Eskalation bei Fehlschlägen.
I/O & Ressourcen
- Build-Artefakt / Container-Image
- Minimaler Satz an Testdaten
- Automatisierte Testskripte oder Checklisten
- Pass/Fail-Status
- Fehler-Logs und erste Diagnosehinweise
- Entscheidungsempfehlung (Rollback, Release, Debug)
Beschreibung
Sanity Testing ist eine schlanke Prüfungspraktik, die nach kleinen Code- oder Konfigurationsänderungen ausgeführt wird, um zentrale Funktionen schnell zu verifizieren. Sie verhindert, dass fehlerhafte Grundzustände Ressourcen in aufwändigere Regressionstests investieren. Sanity-Tests sind fokussiert, kurz, häufig automatisierbar und werden in CI-Pipelines integriert, um rasches Feedback zu liefern.
✔Vorteile
- Schnelle Erkennung von schwerwiegenden Problemen unmittelbar nach Änderungen.
- Reduzierung verschwendeter Zeit bei langlaufenden Regressionstests.
- Einfachere Entscheidungsgrundlage für Rollbacks oder Freigaben.
✖Limitationen
- Keine vollständige Qualitätsgarantie; tiefergehende Tests bleiben nötig.
- Kann False-Positives verursachen, wenn Testdaten oder Umgebungen inkonsistent sind.
- Nicht geeignet, um Performance- oder Skalierungsprobleme umfassend zu prüfen.
Trade-offs
Metriken
- Durchlaufzeit der Sanity-Suite
Misst die durchschnittliche Zeit, die zur Ausführung der Sanity-Tests benötigt wird.
- Fehlschlagsrate pro Build
Anteil der Builds, bei denen Sanity-Tests fehlschlagen.
- Zeit bis zur ersten Rückmeldung
Zeitspanne zwischen Build-Start und Verfügbarkeit des Sanity-Testergebnisses.
Beispiele & Implementierungen
Web-API: Health- und Auth-Checks
Sanity-Suite prüft Status-Endpunkt, grundlegende Authentifizierung und DB-Verbindung nach Deployment.
Microservice: Start-up Smoke
Nach Container-Start werden Kern-APIs und Konfigurationswerte geprüft, um Startfehler früh zu erkennen.
Frontend: Basale UI-Workflows
Automatisierte Sanity-Tests prüfen, ob Login, Navigation und Kerndialoge erreichbar sind.
Implementierungsschritte
Identifiziere kritische Pfade und minimale Testfälle.
Implementiere automatisierte Sanity-Skripte und integriere sie in CI-Jobs.
Definiere klare Schwellenwerte und Benachrichtigungsprozesse für Fehlschläge.
Überwache und pflege die Suite regelmäßig, um Flakiness zu reduzieren.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Veraltete Testskripte ohne Refactoring.
- Fehlende Parameterisierung von Testdaten.
- Monolithische Sanity-Suiten statt modularer Checks.
Bekannte Engpässe
Beispiele für Missbrauch
- Verwenden von Sanity-Tests als einzigen Release-Gate.
- Aufblähen der Suite mit nicht-kritischen Prüfungen.
- Manuelle Sanity-Checks in CI-Prozessen statt Automatisierung.
Typische Fallen
- Zu breiter Umfang zerstört das Ziel der Schnelligkeit.
- Mangelnde Wartung führt zu wachsender Fehleranfälligkeit.
- Unklare Verantwortlichkeiten für Pflege und Reaktion.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte Zeitbudget für schnelle Checks
- • Zugänglichkeit stabiler Testumgebungen
- • Notwendigkeit deterministischer Testdaten