Zum Inhalt springen
SDETRole
SDETRole

Glossar · Testgrundlagen

Codeabdeckung (Code Coverage)

Englisch: Code coverage

Auch genannt: Testabdeckung, Anweisungsüberdeckung, Zweigüberdeckung, Line Coverage

Definition

Der Anteil des Quellcodes (Zeilen, Anweisungen, Zweige oder Funktionen), der beim Testlauf ausgeführt wird. Sie zeigt, was ungetestet ist, nicht was gut getestet ist.

Die Codeabdeckung misst, wie viel des Codes bei einem Testlauf ausgeführt wurde. Ein Tool instrumentiert den Code (JaCoCo für Java, Istanbul/nyc oder V8-Coverage für JavaScript, coverage.py für Python), führt die Tests aus und berichtet, welche Zeilen und Zweige durchlaufen wurden. Sie ist eine White-Box-Metrik und wird meist für Unit- und Integrationstests erhoben.

Arten der Abdeckung

Betrachten Sie:

int shippingCost(double total, boolean isMember) {
    if (total >= 100 || isMember) {
        return 0;
    }
    return 5;
}
  • Anweisungsüberdeckung (Zeilenabdeckung): Wurden beide return-Anweisungen ausgeführt? Zwei Tests, (150, false) und (20, false), ergeben 100 %.
  • Zweigüberdeckung (Entscheidungsüberdeckung): War das if einmal wahr und einmal falsch? Dieselben zwei Tests ergeben ebenfalls 100 %.
  • Bedingungsüberdeckung: Hat jede boolesche Teilbedingung einmal wahr und einmal falsch ergeben? Die Tests oben haben isMember nie wahr gemacht, also ist sie nicht vollständig. Mit (20, true) ist das behoben.
  • Funktionsüberdeckung: Wurde jede Funktion mindestens einmal aufgerufen?

Die Zweigüberdeckung ist in der Regel ein sinnvolleres Ziel als die Zeilenabdeckung, denn eine Zeile kann mehrere Pfade verbergen.

Was die Abdeckung nicht verrät

Abdeckung beweist, dass Code lief, nicht dass er geprüft wurde. Dieser Test ergibt 100 % Zeilen- und Zweigüberdeckung für die Methode oben und verifiziert nichts:

@Test
void runsShippingCost() {
    shippingCost(150, false);
    shippingCost(20, false);
}

Abdeckung kann auch fehlenden Code nicht aufdecken. Wenn die Anforderung besagt, dass Mitglieder in einer bestimmten Region Versand zahlen, und niemand das implementiert hat, gibt es keine Zeilen, die unabgedeckt bleiben könnten. Mutation Testing ist der übliche Weg, um zu messen, ob Tests Fehler tatsächlich erkennen.

Sinnvoll einsetzen

  • Schauen Sie auf die nicht abgedeckten Zeilen, nicht nur auf die Zahl. Ein ungetesteter Error Handler im Zahlungspfad ist wichtiger als ein ungetestetes toString().
  • Setzen Sie ein Gate auf die Abdeckung geänderten Codes, etwa „neuer Code muss mindestens 80 % Zweigüberdeckung haben“, statt auf einen globalen Prozentwert, der dazu verleitet, triviale Getter zu testen.
  • Machen Sie 100 % nie zum Ziel. Wird eine Kennzahl zum Ziel, tauchen Tests ohne Assertions auf.

Tippen Sie, um SDETRole zu durchsuchen.

Volltextsuche mit Pagefind · läuft in Ihrem Browser Suchseite öffnen →