Close

Einführung in die Codeabdeckung

In diesem Artikel erfährst du, wie du mit der Codeabdeckung beginnst, wie du das richtige Tool findest und wie die Berechnung funktioniert.

Porträt von Sten Pittet
Sten Pittet

Gastautor


Codeabdeckung ist eine Metrik, mit der du ermitteln kannst, welcher Anteil deines Quellcodes bereits getestet wurde. Sie hilft dir, die Qualität deiner Test-Suite zu beurteilen und herauszufinden, wie du deine Projekte beginnen kannst.

Wie wird die Codeabdeckung berechnet?


Codeabdeckungstools verwenden mehrere Kriterien, um zu bestimmen, wie und ob dein Code bei der Ausführung der Test-Suite ausgeführt wurde. Hier sind häufige Metriken, die in deinen Abdeckungsberichten auftauchen können:

  • Funktionsabdeckung: Wie viele der definierten Funktionen wurden aufgerufen?
  • Anweisungsabdeckung: Wie viele Anweisungen im Programm wurden ausgeführt?
  • Branch-Abdeckung: Wie viele Branches der Kontrollstrukturen (zum Beispiel if-Anweisungen) wurden ausgeführt?
  • Bedingungsabdeckung: Wie viele Boolesche Unterausdrücke wurden auf einen True- und False-Wert getestet?
  • Zeilenabdeckung: Wie viele Zeilen des Quellcodes wurden getestet?

Diese Metriken werden in der Regel anhand der Anzahl der tatsächlich getesteten Elemente, der im Code gefundenen Elemente und eines Prozentsatzes der Abdeckung (Verhältnis zwischen getesteten und gefundenen Elementen) verdeutlicht.

Diese Metriken sind verwandt, aber unterschiedlich. Das Skript unten zeigt eine JavaScript-Funktion, die prüft, ob ein Argument ein Vielfaches von 10 ist. Wir werden diese Funktion später verwenden, um zu überprüfen, ob 100 ein Vielfaches von 10 ist. Daran möchten wir zeigen, was der Unterschied zwischen einer Funktions- und einer Branch-Abdeckung ist.

Lösung anzeigen

Hochwertige Software entwickeln und ausführen mit Open DevOps

Zugehöriges Material

Automatisiertes Testen für DevOps

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else    return false; }   console.log(isMultipleOf10(100));


Mit dem Abdeckungstool istanbul können wir herausfinden, wie viel unseres Codes bei der Ausführung dieses Skripts ausgeführt wird. Nach dem Ausführen des Abdeckungstools erhalten wir einen Abdeckungsbericht mit unseren Abdeckungsmetriken. Dieser informiert uns darüber, dass unsere Funktionsabdeckung 100 % beträgt, die Branch-Abdeckung jedoch nur 50 %. Wir erfahren außerdem, dass das Codeabdeckungstool istanbul die Metrik Bedingungsabdeckung nicht berechnet.

Einen Abdeckungsbericht in der Befehlszeile abrufen

Dies liegt daran, dass beim Ausführen unseres Skripts die else-Anweisung nicht ausgeführt wurde. Wenn wir eine 100%ige Abdeckung erhalten möchten, könnten wir einfach eine weitere Zeile hinzufügen, die im Wesentlichen ein weiterer Test ist, um sicherzustellen, dass alle Branches der if-Anweisung verwendet werden.

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else     return false; }   console.log(isMultipleOf10(100)); console.log(isMultipleOf10(34)); // This will make our code execute the "return false;" statement.  


Wenn wir unser Abdeckungstool nun ein zweites Mal ausführen, sehen wir, dass dank der zwei console.log()-Anweisungen unten 100 % des Quellcodes abdeckt werden.

Eine hundertprozentige Abdeckung für alle Kriterien abrufen

In diesem Beispiel haben wir nur Ergebnisse im Terminal protokolliert, aber das gleiche Prinzip gilt, wenn du deine Test-Suite ausführst. Dein Codeabdeckungstool überwacht die Ausführung deiner Test-Suite und informiert dich, wie viele der Anweisungen, Branches, Funktionen und Zeilen im Rahmen deines Tests ausgeführt wurden.

istanbul für JavaScript kann einen umfassenden Bericht der Abdeckung für jeden Pfad anzeigen

Erste Schritte mit der Codeabdeckung


Finde das richtige Tool für dein Projekt

Je nachdem, welche Sprache(n) du verwendest, gibt es unterschiedliche Tools zur Erstellung von Abdeckungsberichten. Beliebte Tools sind zum Beispiel:

Einige Tools wie istanbul geben die Ergebnisse direkt im Terminal aus, während andere einen vollständigen HTML-Bericht erstellen können, mit dem du untersuchen kannst, welcher Teil des Codes nicht abgedeckt wurde.

Welche Abdeckung (Prozentsatz) als Ziel?

Es gibt keine Universallösung für die Codeabdeckung und selbst eine hohe Abdeckung kann problematisch sein, wenn kritische Anwendungskomponenten nicht getestet werden oder wenn die vorhandenen Tests nicht robust genug sind, um Fehler im Voraus richtig zu erfassen. Im Allgemeinen wird jedoch eine Abdeckung von 80 % angestrebt. Der Versuch, eine höhere Abdeckung zu erreichen, kann teuer werden und zahlt sich nicht unbedingt aus.

Wenn du dein Abdeckungstool zum ersten Mal ausführst, fällt dir vielleicht auf, dass die Abdeckung noch recht niedrig ist. Wenn du gerade mit dem Testen beginnst, ist es aber ganz normal, dass du nicht gleich eine Abdeckung von 80 % erreichst. Du solltest dein Team nicht dazu drängen, Tests zu schreiben, die jede Codezeile abdecken. Stattdessen sollten sich die Tests auf die Geschäftsanforderungen deiner Anwendung konzentrieren.

Beispielsweise haben wir im obigen Beispiel eine 100%ige Abdeckung erreicht, als wir getestet haben, ob 100 und 34 ein Vielfaches von 10 sind. Aber was wäre, wenn wir unsere Funktion mit einem Buchstaben statt einer Zahl abrufen würden? Sollten wir ein True/False-Ergebnis erhalten? Oder eine Ausnahme? Gib deinem Team genug Zeit, bei den Tests aus der Benutzerperspektive zu denken, anstatt sich nur mit Code zu befassen. Codeabdeckung ist nicht dafür gedacht, fehlende Elemente in deinem Quellcode aufzuzeigen.

Führe zunächst Unit-Tests durch

Unit-Tests prüfen, ob die einzelnen Methoden der von deiner Anwendung genutzten Klassen und Komponenten funktionieren. Sie sind in der Regel günstig zu implementieren, schnell auszuführen und geben dir die Sicherheit, dass deine Plattform über eine solide Grundlage verfügt. Mit Unit-Tests kannst du die Codeabdeckung schnell und einfach erhöhen, da du prüfen kannst, ob deine Test-Suite alle Codezeilen abdeckt.

Verwende die Abdeckungsberichte, um während der Testphase kritische Fehler zu identifizieren

Schnell werden sich so viele Tests in deinem Code angehäuft haben, dass du nicht mehr sagen kannst, welcher Teil der Anwendung bei der Ausführung deiner Test-Suite geprüft wird. Ein roter Build zeigt dir an, wenn etwas nicht stimmt, aber es ist schwierig, nachzuvollziehen, welche Komponenten die Tests bestanden haben.

In diesem Fall können Abdeckungsberichte Teams praktische Anweisungen aufzeigen. Die meisten Tools verfügen über Abdeckungsberichte, mit denen du genauer erforschen kannst, welche Elemente nicht von Tests abgedeckt wurden. So kannst du kritische Bereiche deiner Anwendung identifizieren, die noch getestet werden müssen.

SimpleCov for Ruby kann dir zeigen, welche Methoden noch nicht getestet wurden

Mache Codeabdeckung zu einem Teil deiner Continuous-Integration-Strategie, wenn du bereit bist

Sobald du einen Continuous-Integration-Workflow eingerichtet hast, kannst du festlegen, dass Tests nicht bestanden werden, wenn ein bestimmter Abdeckungsprozentsatz nicht erreicht wird. Wie bereits erwähnt, solltest du die Schwelle für das Nichtbestehen nicht zu hoch ansetzen, und eine Abdeckung von 90 % führt wahrscheinlich dazu, dass dein Build den Test nur selten besteht. Wenn du 80 % Abdeckung erreichen möchtest, empfehlen wir dir zur Sicherheit die Schwelle für das Nichtbestehen auf 70 % festzulegen.

Außerdem solltest du dein Team nicht unter Druck setzen, eine hohe Abdeckung zu erreichen, da dies zu schlechten Testverfahren führen kann.

Eine gute Abdeckung heißt nicht, dass auch die Tests gut sind

Für erfolgreiche Tests sollte dein Team wissen, wie sich eine Anwendung verhält, wenn sie richtig verwendet wird, aber auch, wenn jemand versucht, absichtlich Fehler hervorzurufen. Codeabdeckungstools können dir zeigen, worauf du dich als Nächstes konzentrieren solltest, aber sie zeigen dir nicht, ob deine bestehenden Tests solide genug für unerwartetes Verhalten sind.

Eine hohe Abdeckung ist ein gutes Ziel, das aber mit einer robusten Test-Suite einhergehen sollte, die sicherstellt, dass keine Fehler bei individuellen Klassen vorliegen und die die Integrität des Systems überprüfen kann.

Erfahre mehr über die unterschiedlichen Arten von Softwaretests.

Sten Pittet
Sten Pittet

Ich bin seit 10 Jahren in der Softwarebranche tätig und hatte schon verschiedene Positionen inne, unter anderem in der Entwicklung und im Produktmanagement. Nachdem ich in den letzten 5 Jahren bei Atlassian an Entwickler-Tools gearbeitet habe, schreibe ich jetzt über das Erstellen von Software. In meiner Freizeit feile ich zusammen mit meinem Kleinkind an meinen Kompetenzen als Vater.


Diesen Artikel teilen

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Abbildung: DevOps

DevOps-Community

Abbildung: DevOps

Blog lesen

Abbildung: Karte

Kostenlos loslegen

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up