Was ist ein angemessener Prozentsatz für die Codeabdeckung von Unit-Tests (und warum)?

Question

Wenn Sie einen Mindestprozentsatz an Code-Abdeckung für Unit-Tests vorschreiben würden, vielleicht sogar als Voraussetzung für die Übergabe an ein Repository, wie hoch wäre er?

Erläutern Sie bitte, wie Sie zu Ihrer Antwort gekommen sind (denn wenn Sie nur eine Zahl ausgewählt haben, hätte ich das auch selbst tun können ;)

Answer 1

Ich hätte noch einen weiteren Ansatz zur Testabdeckung, den ich gerne mit Ihnen teilen würde.

Wir haben ein großes Projekt, bei dem ich über Twitter festgestellt habe, dass, mit 700 Unit-Tests haben wir nur eine Codeabdeckung von 20%. .

Scott Hanselman antwortete mit Worte der Weisheit :

Sind es die RICHTIGEN 20 %? Sind es die 20% die den Code darstellen, den Ihre Nutzer am häufigsten aufrufen? Sie könnten 50 weitere Tests und fügen nur 2 % hinzu.

Und wieder geht es zurück zu meinem Testivus über Code Coverage Antwort. Wie viel Reis sollte man in den Topf geben? Das kommt darauf an.

Answer 2

In vielen Geschäften werden Tests nicht gewertet. Wenn Sie also über Null liegen, gibt es zumindest eine gewisse Wertschätzung - daher ist es wohl nicht schlecht, wenn Sie nicht bei Null liegen, denn viele sind immer noch bei Null.

In der .Net-Welt werden oft 80% als vernünftig bezeichnet. Aber sie sagen das auf Lösungsebene. Ich ziehe es vor, auf Projektebene zu messen: 30 % könnten für ein UI-Projekt in Ordnung sein, wenn Sie Selenium usw. oder manuelle Tests haben, 20 % für das Datenschichtprojekt könnten in Ordnung sein, aber 95 % und mehr könnten für die Geschäftsregelschicht durchaus erreichbar sein, wenn auch nicht ganz notwendig. Die Gesamtabdeckung kann also beispielsweise 60 % betragen, aber die kritische Geschäftslogik kann viel höher sein.

Ich habe auch Folgendes gehört: Strebe nach 100 % und du wirst 80 % erreichen; aber strebe nach 80 % und du wirst 40 % erreichen.

Unterm Strich: Wenden Sie die 80:20-Regel an und lassen Sie sich von der Anzahl der Fehler in Ihrer Anwendung leiten.

Answer 3

Für ein gut konzipiertes System, bei dem Unit-Tests die Entwicklung von Anfang an vorangetrieben haben, würde ich sagen, dass 85 % eine recht niedrige Zahl ist. Bei kleinen Klassen, die so konzipiert sind, dass sie testbar sind, sollte es nicht schwer sein, mehr als das abzudecken.

Es ist leicht, diese Frage mit einem Satz wie diesem abzutun:

• Gedeckte Linien sind nicht gleich geprüfte Logik, und man sollte nicht zu viel in den Prozentsatz hineininterpretieren.

Stimmt, aber es gibt einige wichtige Punkte zur Codeabdeckung zu sagen. Meiner Erfahrung nach ist diese Metrik tatsächlich recht nützlich, wenn sie richtig eingesetzt wird. Abgesehen davon habe ich nicht alle Systeme gesehen, und ich bin sicher, dass es tonnenweise Systeme gibt, bei denen die Analyse der Codeabdeckung kaum einen echten Mehrwert bringt. Der Code kann so unterschiedlich aussehen und der Umfang des verfügbaren Test-Frameworks kann variieren.

Außerdem bezieht sich meine Argumentation hauptsächlich auf recht kurze Testrückkopplungsschleifen. Für das Produkt, das ich entwickle, ist die kürzeste Rückkopplungsschleife recht flexibel und deckt alles ab, von Klassentests bis zur prozessübergreifenden Signalisierung. Das Testen eines lieferbaren Teilprodukts dauert in der Regel 5 Minuten, und bei einer so kurzen Feedbackschleife ist es in der Tat möglich, die Testergebnisse (und insbesondere die hier betrachtete Codeabdeckungsmetrik) zu verwenden, um Commits im Repository abzulehnen oder zu akzeptieren.

Bei der Verwendung der Codeabdeckungsmetrik sollten Sie nicht nur einen festen (willkürlichen) Prozentsatz vorgeben, der erfüllt werden muss. Meiner Meinung nach bietet dies nicht die wirklichen Vorteile der Codeabdeckungsanalyse. Definieren Sie stattdessen die folgenden Metriken:

• Low Water Mark (LWM), die niedrigste Anzahl unbedeckter Linien, die jemals im geprüften System beobachtet wurde
• High Water Mark (HWM), der höchste Prozentsatz an Codeabdeckung, der jemals für das zu testende System erreicht wurde

Neuer Code kann nur hinzugefügt werden, wenn wir nicht über die LWM und nicht unter die HWM gehen. Mit anderen Worten, die Codeabdeckung ist darf nicht abnehmen und der neue Code sollte abgedeckt sein. Beachten Sie, dass ich "sollte" und nicht "muss" sage (siehe unten).

Aber bedeutet das nicht, dass es unmöglich ist, alten, gut getesteten Müll zu entsorgen, für den man keine Verwendung mehr hat? Ja, und deshalb muss man in diesen Dingen pragmatisch sein. Es gibt Situationen, in denen die Regeln gebrochen werden müssen, aber für Ihre typische alltägliche Integration sind diese Metriken meiner Erfahrung nach recht nützlich. Daraus ergeben sich die folgenden zwei Implikationen.

• Testbarer Code wird gefördert. Wenn Sie neuen Code hinzufügen, müssen Sie sich wirklich bemühen, den Code testbar zu machen, da Sie versuchen müssen, den gesamten Code mit Ihren Testfällen abzudecken. Testbarer Code ist normalerweise eine gute Sache.

• Die Testabdeckung für Legacy-Code nimmt mit der Zeit zu. Wenn man neuen Code hinzufügt und nicht in der Lage ist, ihn mit einem Testfall abzudecken, kann man stattdessen versuchen, einen Teil des alten Codes abzudecken, um die LWM-Regel zu umgehen. Diese manchmal notwendige Schummelei hat zumindest den positiven Nebeneffekt, dass die Abdeckung des Legacy-Codes mit der Zeit zunimmt, was die scheinbar strenge Durchsetzung dieser Regeln in der Praxis recht pragmatisch macht.

Und noch einmal: Wenn die Rückkopplungsschleife zu lang ist, könnte es völlig unpraktisch sein, so etwas im Integrationsprozess einzurichten.

Ich möchte noch zwei weitere allgemeine Vorteile der Codeabdeckungsmetrik erwähnen.

• Die Code-Abdeckungsanalyse ist Teil der dynamischen Code-Analyse (im Gegensatz zur statischen Analyse, z. B. Lint). Probleme, die während der dynamischen Code-Analyse gefunden werden (durch Werkzeuge wie die purify-Familie, http://www-03.ibm.com/software/products/en/rational-purify-family ) sind Dinge wie uninitialisierte Speicherlesevorgänge (UMR), Speicherlecks, usw. Diese Probleme können nur gefunden werden, wenn der Code durch einen ausgeführten Testfall abgedeckt ist . Der Code, der am schwierigsten in einem Testfall abzudecken ist, sind in der Regel die abnormalen Fälle im System, aber wenn Sie wollen, dass das System anständig versagt (d.h. Fehlersuche statt Absturz), sollten Sie sich auch etwas Mühe geben, die abnormalen Fälle in der dynamischen Codeanalyse abzudecken. Mit ein wenig Pech kann eine UMR zu einem Segfault oder Schlimmerem führen.

• Die Leute sind stolz darauf, dass sie 100 % des neuen Codes einhalten, und die Leute diskutieren Testprobleme mit einer ähnlichen Leidenschaft wie andere Implementierungsprobleme. Wie kann diese Funktion auf eine besser testbare Weise geschrieben werden? Wie würden Sie versuchen, diesen abnormalen Fall abzudecken, usw.

Und ein Negativ, der Vollständigkeit halber.

• In einem großen Projekt mit vielen beteiligten Entwicklern wird sicher nicht jeder ein Testgenie sein. Manche Leute neigen dazu, die Codeabdeckungsmetrik als Beweis dafür zu verwenden, dass der Code getestet ist, was jedoch weit von der Wahrheit entfernt ist. wie in vielen anderen Antworten auf diese Frage erwähnt. Es ist EINE Metrik, die bei richtiger Anwendung einige nette Vorteile bringen kann, aber wenn sie missbraucht wird, kann sie in der Tat zu schlechten Tests führen. Abgesehen von den oben erwähnten sehr wertvollen Nebeneffekten zeigt eine abgedeckte Zeile nur, dass das zu testende System diese Zeile für einige Eingabedaten erreichen kann und dass es ausgeführt werden kann, ohne zu hängen oder abzustürzen.

Answer 4

Wäre die Welt perfekt, würden 100 % des Codes durch Unit-Tests abgedeckt. Da dies jedoch NICHT die perfekte Welt ist, kommt es darauf an, wofür man Zeit hat. Ich empfehle daher, sich weniger auf einen bestimmten Prozentsatz zu konzentrieren, sondern mehr auf die kritischen Bereiche. Wenn Ihr Code gut geschrieben ist (oder zumindest ein vernünftiges Faksimile davon), sollte es mehrere Schlüsselpunkte geben, an denen APIs mit anderem Code verbunden sind.

Konzentrieren Sie sich bei Ihren Tests auf diese APIs. Stellen Sie sicher, dass die APIs 1) gut dokumentiert sind und 2) über Testfälle verfügen, die der Dokumentation entsprechen. Wenn die erwarteten Ergebnisse nicht mit der Dokumentation übereinstimmen, dann haben Sie einen Fehler in Ihrem Code, Ihrer Dokumentation oder Ihren Testfällen. All diese Punkte sollten überprüft werden.

Viel Glück!

Answer 5

Die Codeabdeckung ist nur eine weitere Metrik. An und für sich kann sie sehr irreführend sein (siehe www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). Ihr Ziel sollte es daher nicht sein, eine 100%ige Codeabdeckung zu erreichen, sondern vielmehr sicherzustellen, dass Sie alle relevanten Szenarien Ihrer Anwendung testen.