Dotnet Testing
Konzeptuelle Orientierung zu Testprinzipien und -praktiken für .NET-Anwendungen, inklusive Frameworks, Testarten und Integration in CI/CD.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypDesign
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Blindes Vertrauen in Tests ohne Überprüfung der Testqualität.
- Zu enge Kopplung von Tests an Implementierungsdetails erhöht Wartungskosten.
- Fehlende Infrastruktur für reproduzierbare Testumgebungen führt zu False Positives/Negatives.
- Keep tests small, focused und unabhängig voneinander.
- Verwende Mocks für externe Systeme und Testcontainers für Integrationstests.
- Automatisiere Testausführung im CI und überwache Testmetriken.
I/O & Ressourcen
- Quellcode, Build-Skripte und CI-Definitionen
- Testframeworks (xUnit, NUnit) und Mocking-Bibliotheken
- Testinfrastruktur: Container, Testdatenbanken, Stubs
- Automatisierte Testreports und Metriken
- Fehler- und Regressionsberichte
- Verbesserte Codequalität und dokumentiertes Verhalten
Beschreibung
Dotnet Testing beschreibt Prinzipien, Methoden und Praktiken zur Qualitätssicherung von .NET-Anwendungen. Es umfasst Unit-, Integration- und End-to-End-Tests, Testautomatisierung, Testframeworks (xUnit, NUnit), Mocking und Continuous-Testing im CI/CD-Kontext. Es behandelt außerdem Messgrößen, Teststrategien und Risiken bei Testabdeckung und Testflakiness.
✔Vorteile
- Frühe Fehlererkennung reduziert Kosten und Debug-Aufwand.
- Automatisierte Tests ermöglichen schnelle Releases und höhere Zuverlässigkeit.
- Klare Testspezifikationen dienen als lebende Dokumentation des Verhaltens.
✖Limitationen
- Hoher Initialaufwand für Aufbau und Pflege großer Test-Suites.
- Unzureichende Testabdeckung kann falsche Sicherheit erzeugen.
- Flakige Tests verursachen Rauschen und untergraben Vertrauen in die Pipeline.
Trade-offs
Metriken
- Testabdeckung (Code Coverage)
Prozentualer Anteil des von Tests ausgeführten Codes. Indikator für getestete Bereiche, jedoch kein alleiniges Qualitätsmaß.
- Bau-/Pipeline-Dauer
Gesamtlaufzeit der CI-Pipeline inklusive Tests; wichtig für Feedbackgeschwindigkeit.
- Flakiness-Rate
Anteil intermittierender Testfehler; misst Stabilität der Testbasis.
Beispiele & Implementierungen
Bibliotheksprojekt mit xUnit
Kleines NuGet-Paket verwendet umfangreiche Unittests mit xUnit und Mocking zur Absicherung von API-Verhalten.
Microservice-Integrationstest
Integrationstestkette startet Postgres- und RabbitMQ-Container via Testcontainers und validiert Nachrichtenflüsse.
E2E-Tests für ASP.NET Core App
End-to-End-Tests automatisieren Benutzerfälle gegen eine in Testumgebung bereitgestellte Web-App und prüfen kritische Pfade.
Implementierungsschritte
Evaluieren von Testframeworks und Konventionen festlegen
CI-Pipeline erweitern und Testläufe automatisieren
Metriken einführen, Flakiness analysieren und Tests stabilisieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unzureichend modularer Legacy-Code erschwert Testisolierung.
- Veraltete Testframeworks oder unstrukturierte Testorganisation.
- Fehlende CI-Kapazität führt zu langsamen Feedbackzyklen.
Bekannte Engpässe
Beispiele für Missbrauch
- Vertrauen auf 100% Coverage als alleiniges Qualitätsziel.
- UI-Tests als einzige Testschicht für kritische Logik.
- Mocken von zu vielen internen Details statt klarer Schnittstellen.
Typische Fallen
- Zeitlimits in CI setzen, die zu häufigen Timeout-Fehlern führen.
- Tests blind parallelisieren ohne Rücksicht auf shared state.
- Keine Beobachtbarkeit für Testfehlerlogs bereitstellen.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte CI-Ressourcen für parallele Testläufe
- • Legacy-Code ohne klare Schnittstellen erschwert Isolation
- • Regulatorische Vorgaben für Testdaten und Datenschutz