Dotnet-Testframework
Kategorisierung von Testframeworks, Patterns und Werkzeugen für .NET-Anwendungen zur Sicherstellung von Qualität über Unit-, Integrations- und End-to-End-Tests.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypTechnisch
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlende Test-Isolation führt zu schwer reproduzierbaren Fehlern.
- Übermäßige Abhängigkeit von Mocks verfälscht Integrationsverhalten.
- Unzureichende Testdatenmanagement verursacht inkonsistente Ergebnisse.
- Schreibe kleine, deterministische Unit-Tests mit klaren Assertions.
- Kategorisiere Tests und priorisiere schnelle Rückmeldungen.
- Verwende parametrische Tests und Testdatenmanagement zur Reduktion von Duplikaten.
I/O & Ressourcen
- Quellcode und Build-Artefakte
- Testdaten und Mocks
- CI/CD-Infrastruktur und Runner
- Testberichte und Metriken
- Release-Blocker bei fehlschlagenden Tests
- Verbesserte Regressionserkennung
Beschreibung
Das Dotnet-Testframework beschreibt das Ökosystem von Testbibliotheken, Patterns und Werkzeugen zur Validierung von .NET-Anwendungen auf Unit-, Integrations- und End-to-End-Ebene. Es behandelt Framework-Auswahl, Testarchitektur, CI/CD-Automatisierung und Abwägungen wie Geschwindigkeit gegenüber Isolation. Es unterstützt Entscheidungskriterien für Adoption und Integration in bestehende Build- und Release-Prozesse.
✔Vorteile
- Früherkennung von Fehlern während Entwicklung.
- Erhöhte Regression-Sicherheit bei Releases.
- Klare Metriken zur Messung von Testqualität und Coverage.
✖Limitationen
- Tests erhöhen den Wartungsaufwand und müssen gepflegt werden.
- Vollständige E2E-Abdeckung ist zeit- und ressourcenintensiv.
- Flaky Tests können Vertrauen in die Pipeline untergraben.
Trade-offs
Metriken
- Code-Coverage
Prozentsatz des getesteten Codes; Indikator für Testabdeckung, jedoch kein alleiniges Qualitätsmaß.
- Test-Durchlaufzeit
Gesamtdauer der Testausführung, wichtig für Feedback-Zyklen und CI-Performance.
- Flakiness-Rate
Anteil intermittierender Fehler in Testläufen, beeinflusst Vertrauen in die Pipeline.
Beispiele & Implementierungen
xUnit für .NET Core-Projekt
Ein Microservice verwendet xUnit für Unit-Tests, kombiniert mit Moq für Isolation und GitHub Actions für CI.
Integrationstests mit NUnit und TestServer
API-Integrationstests nutzen NUnit und ASP.NET Core TestServer, um Endpunkte ohne produktive Infrastruktur zu prüfen.
End-to-End-Tests mit Playwright und .NET
Browser-basierte End-to-End-Tests sind mit Playwright eingebunden, orchestriert in der CI-Pipeline zur Release-Qualifikation.
Implementierungsschritte
Auswahl passender Testframeworks basierend auf Projektanforderungen
Einrichtung von Testprojekten und Standard-Templates
Integration der Testausführung in die CI/CD-Pipeline
⚠️ Technische Schulden & Engpässe
Tech Debt
- Fehlende Testabdeckung in kritischen Pfaden
- Veraltete Test-Framework-Versionen im Repo
- Unstrukturierte Testdaten und manuelle Testvorbereitung
Bekannte Engpässe
Beispiele für Missbrauch
- Vertrauen ausschließlich auf hohe Coverage, obwohl Tests oberflächlich sind.
- Ausführen teuerer E2E-Tests bei jedem Commit statt selektiver Runs.
- Komplexe Integrationstests ohne Isolation und deterministische Daten.
Typische Fallen
- Unklare Testverantwortung zwischen Teams führt zu duplizierten Tests.
- Ignorieren von Flaky-Tests anstatt deren Ursachen zu beheben.
- Metriken manipulieren, um Qualitätskennzahlen zu schönzureden.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte CI-Ressourcen für parallele Tests
- • Legacy-Code ohne Testbarkeit
- • Compliance-Anforderungen für Testdaten