Code-Abdeckung in C#: Von Metriken zur Qualität

Warum „grüne“ Tests noch kein Sieg sind?

Stellen Sie sich vor: Sie haben hundert Unit-Tests geschrieben, alle bestehen mit einem grünen Häkchen, die CI-Pipeline ist glücklich, der Manager zufrieden. Aber einen Monat später fällt eine kritische Funktion in der Produktion aus. Eine bekannte Geschichte? Meistens liegt das Problem darin, dass wir die falschen Szenarien testen oder ganze Codezweige überspringen.

Code-Abdeckung (Code Coverage) ist nicht nur eine modische Metrik für den Bericht. Sie ist Ihre Taschenlampe im dunklen Raum der Unsicherheit. Als ich anfing, mit C# zu arbeiten, dachte ich, 80% Abdeckung seien das Ideal. Aber dann wurde mir klar: Man kann 100% Zeilenabdeckung haben und dennoch einen Fehler in der Verzweigungslogik übersehen. Deshalb schauen wir uns heute an, wie man die Abdeckung in C# richtig misst, welche Tools wirklich helfen und welche Metriken man verfolgen sollte.

Was ist Code-Abdeckung und warum ist sie für C#-Entwickler wichtig?

Einfach ausgedrückt zeigt die Code-Abdeckung, wie viel Prozent des Quellcodes Ihrer Anwendung während der Testausführung ausgeführt wurden. Wenn Sie einen Test geschrieben haben, der die Methode CalculateDiscount() aufruft, aber den Zweig if (isPremiumUser) nicht prüft, bleibt dieser Zweig „unabgedeckt“.

Für einen C#-Entwickler ist die Abdeckung ein Indikator für zwei Dinge:

\n
• Vertrauen in Refactoring — Kann man Code ändern, ohne Angst zu haben, etwas zu beschädigen?
\n
• Vollständigkeit der Tests — Haben wir Grenzfälle vergessen?
\n

Aber es gibt eine wichtige Nuance: Code-Abdeckung in C# garantiert nicht die Abwesenheit von Fehlern. Sie sagt lediglich, dass bestimmte Zeilen ausgeführt wurden. Deshalb schauen wir nicht nur auf den Prozentsatz, sondern auf die spezifischen Metriken.

Wichtige Metriken der Code-Abdeckung in .NET

Wenn Sie eine Abdeckungsanalyse in C# durchführen, stoßen Sie auf verschiedene Arten von Metriken. Lassen Sie uns jede anhand eines realen Codebeispiels durchgehen.

Line Coverage (Zeilenabdeckung)

Die einfachste Metrik. Sie zählt, wie viele Codezeilen von Tests berührt wurden. Beispiel:

public int Add(int a, int b)\n{\n    if (a < 0)          // Zeile 1\n        return 0;       // Zeile 2\n    return a + b;        // Zeile 3\n}

Wenn Ihr Test Add(5, 3) aufruft, werden die Zeilen 1 und 3 ausgeführt. Zeile 2 bleibt unabgedeckt. Die Line Coverage zeigt 66% (2 von 3 Zeilen).

Branch Coverage (Zweigabdeckung)

Eine ehrlichere Metrik. Sie berücksichtigt alle möglichen Ausführungspfade. In unserem Beispiel gibt es zwei Pfade: wenn a < 0 und wenn nicht. Wenn Sie nur den Fall mit einer positiven Zahl geprüft haben, beträgt die Branch Coverage 50%.

Gerade die Branch Coverage deckt oft „Lücken“ in Tests auf. Ich empfehle, bei dieser Metrik 80%+ anzustreben.

Cyclomatic Complexity und ihr Zusammenhang mit der Abdeckung

Obwohl dies keine direkte Abdeckungsmetrik ist, zeigt die zyklomatische Komplexität, wie viele Tests für eine vollständige Abdeckung erforderlich sind. Je höher die Komplexität einer Methode, desto mehr Tests werden benötigt. Wenn Sie eine Methode mit einer zyklomatischen Komplexität von 15 und einer Abdeckung von 90% sehen, testen Sie wahrscheinlich nicht alle Szenarien.

Tools zur Messung der Code-Abdeckung in C#

Im .NET-Ökosystem gibt es mehrere leistungsstarke Tools. Ich stelle die drei bekanntesten vor, mit denen ich selbst gearbeitet habe.

Coverlet — Kostenlos und in .NET integriert

Wenn Sie .NET 6+ verwenden, ist Coverlet bereits über NuGet verfügbar. Es ist mein Lieblingstool für CI/CD, da es keine Installation zusätzlicher Programme erfordert.

Installation:

dotnet add package coverlet.msbuild\ndotnet add package coverlet.collector

Ausführung mit Bericht:

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover

Sie erhalten eine Datei coverage.opencover.xml, die Sie mit ReportGenerator visualisieren können:

dotnet tool install -g dotnet-reportgenerator-globaltool\nreportgenerat