Fallstricke der Codeabdeckung

Question

Ich bin auf der Suche nach Beispielen aus der realen Welt, die zeigen, welche negativen Auswirkungen die Codeabdeckung hat.

Ich habe dies kürzlich bei meiner Arbeit bemerkt, weil eine Richtlinie eine 100%ige Codeabdeckung vorschreibt. Die Codequalität hat sich sicherlich verbessert, aber im Gegenzug scheinen die Tester laxere Testpläne zu schreiben, weil "der Code ja vollständig unitgetestet ist". Infolgedessen sind einige logische Fehler durchgeschlüpft. Die Fehlersuche war wirklich sehr mühsam, denn der Code ist ja vollständig unit-getestet".

Ich denke, das lag zum Teil daran, dass unser Tool nur Aussagen erfasst hat. Trotzdem hätte man die Zeit besser nutzen können.

Falls jemand andere negative Auswirkungen einer Code Coverage Policy kennt, bitte ich um Mitteilung. Ich würde gerne wissen, was für andere "Probleme" in der Praxis auftreten.

Vielen Dank im Voraus.

EDIT: Danke für all die wirklich guten Antworten. Es gibt ein paar, die ich als Antwort markieren würde, aber ich kann leider nur eine markieren.

Answer 1

In einem Satz: Die Codeabdeckung sagt Ihnen, was Sie definitiv haben nicht getestet, nicht was Sie haben.

Ein Teil des Aufbaus einer wertvollen Unit-Test-Suite besteht darin, den wichtigsten, risikoreichen Code zu finden und ihm schwierige Fragen zu stellen. Sie wollen sicherstellen, dass die schwierigen Dinge vorrangig funktionieren. Abdeckungszahlen haben weder eine Vorstellung von der "Wichtigkeit" des Codes noch von der Qualität der Tests.

Meiner Erfahrung nach sind viele der wichtigsten Tests, die Sie jemals schreiben werden, die Tests, die kaum zur Abdeckung beitragen (Randfälle, die hier und da ein paar zusätzliche % hinzufügen, aber eine Menge Fehler finden).

Das Problem bei der Festlegung von harten und (möglicherweise kontraproduktiven) Abdeckungszielen ist, dass die Entwickler anfangen müssen, sich zu verbiegen, um ihren Code zu testen. Es gibt die Möglichkeit, Code testbar zu machen, und dann gibt es die reine Folter. Wenn Sie mit hervorragenden Tests eine Abdeckung von 100 % erreichen, ist das fantastisch, aber in den meisten Situationen lohnt sich der zusätzliche Aufwand einfach nicht.

Außerdem fangen die Leute an, sich mit Zahlen zu beschäftigen, anstatt sich auf die Qualität der Prüfungen zu konzentrieren. Ich habe schon schlecht geschriebene Tests gesehen, die einen Abdeckungsgrad von mehr als 90 % hatten, genauso wie ich ausgezeichnete Tests gesehen habe, die nur 60-70 % Abdeckungsgrad hatten.

Auch hier neige ich dazu, die Reichweite als einen Indikator dafür zu betrachten, was definitiv hat nicht getestet worden.

Answer 2

Meiner Erfahrung nach besteht das größte Problem mit Codeabdeckungswerkzeugen in der Gefahr, dass jemand dem Glauben verfällt, dass "hohe Codeabdeckung" gleichbedeutend mit "guten Tests" ist. Die meisten Abdeckungs-Tools bieten nur Metriken für die Anweisungsabdeckung, nicht aber für die Abdeckung von Bedingungen, Datenpfaden oder Entscheidungen. Das bedeutet, dass es möglich ist, eine 100%ige Abdeckung für ein Stück Code wie dieses zu erreichen:

for (int i = 0; i < MAX_RETRIES; ++i) {
    if (someFunction() == MAGIC_NUMBER) {
        break;
    }
}

... ohne jemals die Abbruchbedingung der for-Schleife zu testen.

Schlimmer noch, es ist möglich, eine sehr hohe "Abdeckung" durch einen Test zu erhalten, der einfach Ihre Anwendung aufruft, ohne sich die Mühe zu machen, die Ausgabe zu validieren, oder sie falsch zu validieren.

Einfach ausgedrückt, niedrig Code-Abdeckungsgrad ist sicherlich ein Hinweis auf unzureichende Tests, aber hoch Deckungsgrade sind no ein Hinweis auf eine ausreichende oder korrekte Prüfung.

Answer 3

Nur weil es eine Codeabdeckung gibt, heißt das nicht, dass Sie tatsächlich alle Pfade durch die Funktion testen.

Dieser Code hat zum Beispiel vier Pfade:

if (A) { ... } else { ... }
if (B) { ... } else { ... }

Allerdings würden nur zwei Tests (z.B. einer mit A und B wahr, einer mit A und B falsch) eine "100%ige Codeabdeckung" ergeben.

Das ist ein Problem, denn die Tendenz geht dahin, dass man aufhört zu testen, sobald man die magische Zahl von 100 % erreicht hat.

Answer 4

Meiner Meinung nach besteht die größte Gefahr, die ein Team bei der Messung der Codeabdeckung eingeht, darin, dass große Tests belohnt und kleine bestraft werden. Wenn Sie die Wahl haben zwischen dem Schreiben eines einzigen Tests, der einen großen Teil der Funktionalität Ihrer Anwendung abdeckt, und dem Schreiben von zehn kleinen Tests, die eine einzige Methode testen, impliziert die Messung der Codeabdeckung, dass Sie den großen Test schreiben sollten.

Wenn Sie jedoch eine Reihe von 10 kleinen Tests schreiben, erhalten Sie viel weniger spröde Tests und testen Ihre Anwendung viel gründlicher als mit einem einzigen großen Test. Wenn man also die Codeabdeckung misst, vor allem in einem Unternehmen mit sich noch entwickelnden Testgewohnheiten, kann man oft die falschen Anreize setzen.

Answer 5

Manchmal sind Eckfälle so selten, dass es sich nicht lohnt, sie zu testen, aber eine strenge Regel zur Codeabdeckung verlangt, dass man sie trotzdem testet.

In Java ist z. B. der MD5-Algorithmus eingebaut, aber technisch ist es möglich, dass eine Ausnahme vom Typ "nicht unterstützter Algorithmus" ausgelöst wird. Sie wird nie ausgelöst und Ihr Test müsste erhebliche Umwege gehen, um diesen Pfad zu testen.

Das wäre eine Menge vergeudete Arbeit.