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

Diese Prosa von Alberto Savoia beantwortet genau diese Frage (und das auf sehr unterhaltsame Weise!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus zur Testabdeckung

Eines Morgens fragte ein Programmierer den großen Meister:

"Ich bin bereit, einige Unit-Tests zu schreiben. Welche Codeabdeckung sollte ich anstreben anstreben?"

Der große Meister antwortete:

"Machen Sie sich keine Gedanken über die Abdeckung, schreiben Sie einfach ein paar gute Tests."

T ging.

...

L die gleiche Frage gestellt.

Der große Meister zeigte kochendes Wasser und sagte:

"Wie viele Reiskörner soll ich in diesen Topf geben?"

T antwortete:

"Wie kann ich Ihnen das nur sagen? Es hängt davon ab, wie viele Menschen Sie ernähren müssen müssen, wie hungrig sie sind, welche anderen Essen Sie servieren, wie viel Reis Sie zur Verfügung haben, und so weiter."

"Genau", sagte der große Meister.

Der zweite Programmierer lächelte, verbeugte sich, und ging.

...

Gegen Ende des Tages kam ein dritter Programmierer und fragte denselben Frage zur Codeabdeckung.

"Achtzig Prozent und nicht weniger!" Erwiderte der Meister mit strenger Stimme, und schlug mit der Faust auf den Tisch.

Der dritte Programmierer lächelte und verbeugte sich, und ging.

...

Nach dieser letzten Antwort, einer jungen Lehrling an den großen Meister:

"Großer Meister, heute habe ich gehört, wie Sie Codeabdeckung mit drei verschiedenen Antworten. Warum?"

T Stuhl auf:

"Komm und trink einen frischen Tee mit mir und lass uns darüber reden."

A grünem Tee füllten, begann der große begann der große Meister zu antworten:

"Der erste Programmierer ist neu und fängt gerade erst an Im Moment hat er eine Menge Code und keine Tests. Er hat noch einen langen Weg vor sich; sich zu diesem Zeitpunkt auf die Codeabdeckung zu konzentrieren wäre deprimierend und ziemlich nutzlos. Er ist besser dran, wenn er sich einfach daran gewöhnt einige Tests zu schreiben und auszuführen. Er kann später um die Abdeckung kümmern."

"Der zweite Programmierer, auf der anderen im Programmieren und Testen. Als ich antwortete, indem ich sie fragte, wie viele Reiskörner Reiskörner ich in einen Topf geben sollte, habe ich ihr zu verstehen gegeben, dass der Umfang der Tests von einer Reihe von Faktoren abhängt Faktoren abhängt, und sie kennt diese Faktoren besser als ich - es ist ihr es ist schließlich ihr Code. Es gibt keine einzige, einfache Antwort, und sie ist klug genug mit der Wahrheit umzugehen und damit zu arbeiten damit zu arbeiten."

"Ich verstehe", sagte der junge Lehrling, "Aber wenn es keine einzige einfache Antwort gibt Antwort gibt, warum hast du dann das dritten Programmierer 'Achtzig Prozent und nicht weniger'?"

T laut, dass sein Bauch, der Beweis, dass er mehr als nur grünen Tee trank, auf und ab hüpfte.

"Der dritte Programmierer will nur einfache Antworten - auch wenn es keine einfachen Antworten gibt und dann nicht ihnen trotzdem nicht folgen."

T Großmeister tranken ihren Tee Tee in kontemplativem Schweigen.

Answer 2

Die Codeabdeckung ist eine irreführende Kennzahl, wenn Sie eine 100%ige Abdeckung anstreben (anstatt 100%ige Tests aller Funktionen).

• Du könntest 100 % erreichen, wenn du alle Linien einmal triffst. Sie könnten jedoch immer noch verpassen, eine bestimmte Reihenfolge (logischer Pfad) zu testen, in der diese Zeilen getroffen werden.
• Sie konnten keine 100% erreichen, haben aber dennoch alle Ihre 80%/freq verwendeten Code-Pfade getestet. Tests, die jedes "throw ExceptionTypeX" oder eine ähnliche defensive Programmiersperre testen, die Sie eingebaut haben, sind ein "nice to have", kein "must have".

Vertrauen Sie also darauf, dass Sie oder Ihre Entwickler gründlich sind und jeden Pfad durch ihren Code abdecken. Seien Sie pragmatisch und streben Sie nicht nach der magischen 100%igen Abdeckung. Wenn Sie Ihren Code TDD-gestützt entwickeln, sollten Sie als Bonus eine Abdeckung von über 90 % erreichen. Nutzen Sie die Codeabdeckung, um Codeabschnitte hervorzuheben, die Sie übersehen haben (sollte bei TDD nicht passieren, da Sie Code nur schreiben, damit ein Test erfolgreich ist). Kein Code kann ohne seinen Partnertest existieren. )

Answer 3

Jon Limjap bringt es auf den Punkt: Es gibt nicht eine einzige Zahl, die sich als Standard für jedes Projekt eignet. Es gibt Projekte, die einen solchen Standard einfach nicht brauchen. Wo die akzeptierte Antwort meiner Meinung nach zu kurz greift, ist bei der Beschreibung, wie man diese Entscheidung für ein bestimmtes Projekt treffen könnte.

Ich werde einen Versuch wagen, dies zu tun. Ich bin kein Experte für Prüftechnik und würde mich über eine fundiertere Antwort freuen.

Wann sind die Anforderungen an den Erfassungsbereich des Codes festzulegen?

Erstens: Warum wollen Sie eine solche Norm überhaupt einführen? Ganz allgemein, wenn Sie empirisches Vertrauen in Ihr Verfahren einführen wollen. Was meine ich mit "empirischem Vertrauen"? Nun, das eigentliche Ziel Korrektheit . Bei der meisten Software können wir dies unmöglich für alle Eingaben wissen, also geben wir uns mit der Aussage zufrieden, dass der Code erprobt . Dies ist zwar besser zu erkennen, aber immer noch ein subjektiver Maßstab: Es wird immer umstritten sein, ob man ihn erfüllt hat oder nicht. Diese Debatten sind nützlich und sollten geführt werden, aber sie bringen auch Unsicherheit mit sich.

Code-Abdeckung ist eine objektive Messung: Sobald Sie Ihren Erfassungsbericht sehen, gibt es keine Unklarheiten mehr darüber, ob die Standards erfüllt wurden oder nicht. Beweist er die Korrektheit? Keineswegs, aber es besteht ein klarer Zusammenhang damit, wie gut der Code getestet ist, was wiederum unsere beste Möglichkeit ist, das Vertrauen in seine Korrektheit zu erhöhen. Die Codeabdeckung ist ein messbarer Näherungswert für unermessliche Qualitäten, die uns wichtig sind.

Einige spezifische Fälle, in denen ein empirischer Standard von Nutzen sein könnte:

• Die Interessengruppen zufriedenstellen. Bei vielen Projekten gibt es verschiedene Akteure, die ein Interesse an der Softwarequalität haben, aber möglicherweise nicht an der täglichen Entwicklung der Software beteiligt sind (Manager, technische Leiter usw.): Sie müssen sich entweder voll und ganz auf das Projekt verlassen oder es unter ständiger strenger Aufsicht überprüfen (vorausgesetzt, sie haben überhaupt das technische Verständnis dafür).
• Das Verhalten des Teams zu normalisieren. Wenn Sie in einem Team arbeiten, in dem mehrere Personen Code und Tests schreiben, gibt es viel Raum für Unklarheiten darüber, was als "gut getestet" gilt. Haben alle Ihre Kollegen die gleiche Vorstellung davon, welches Testniveau gut genug ist? Wahrscheinlich nicht. Wie können Sie das unter einen Hut bringen? Finden Sie einen Maßstab, auf den Sie sich alle einigen können, und akzeptieren Sie ihn als vernünftigen Näherungswert. Dies ist vor allem (aber nicht ausschließlich) in großen Teams nützlich, in denen die Leiter beispielsweise keine direkte Aufsicht über die jüngeren Entwickler haben. Vertrauensnetze sind ebenfalls wichtig, aber ohne objektive Messwerte kann das Gruppenverhalten leicht inkonsistent werden, selbst wenn alle in gutem Glauben handeln.
• Damit Sie ehrlich bleiben. Selbst wenn Sie der einzige Entwickler und der einzige Beteiligte an Ihrem Projekt sind, haben Sie vielleicht bestimmte Eigenschaften für die Software im Sinn. Anstatt ständig subjektive Einschätzungen darüber abzugeben, wie gut die Software getestet ist (was viel Arbeit bedeutet), können Sie die Codeabdeckung als vernünftigen Näherungswert verwenden und sie von Maschinen messen lassen.

Welche Metriken sind zu verwenden?

Die Codeabdeckung ist keine einheitliche Kennzahl; es gibt mehrere verschiedene Möglichkeiten, die Abdeckung zu messen. Auf welche Sie einen Standard setzen, hängt davon ab, was Sie mit diesem Standard erreichen wollen.

Ich werde zwei gängige Messgrößen als Beispiele dafür anführen, wann man sie zur Festlegung von Standards verwenden kann:

• Erfassungsbereich : Wie viel Prozent der Anweisungen wurden während des Tests ausgeführt? Nützlich, um ein Gefühl für die physische Deckung deines Codes: Wie viel von dem Code, den ich geschrieben habe, habe ich tatsächlich getestet?
  • Diese Art der Abdeckung unterstützt ein schwächeres Korrektheitsargument, ist aber auch einfacher zu erreichen. Wenn Sie Code Coverage nur verwenden, um sicherzustellen dass Dinge getestet werden (und nicht als Indikator für die Testqualität darüber hinaus), dann ist die Anweisungsabdeckung wahrscheinlich ausreichend.
• Abdeckung der Branche : Wenn es eine Verzweigungslogik gibt (z. B. eine if ), sind beide Zweige bewertet worden? Dies vermittelt ein besseres Gefühl für die logische Abdeckung deines Codes: Wie viele der möglichen Wege, die mein Code nehmen kann, habe ich getestet?
  • Diese Art der Abdeckung ist ein viel besserer Indikator dafür, dass ein Programm mit einem umfassenden Satz von Eingaben getestet wurde. Wenn Sie die Codeabdeckung als besten empirischen Näherungswert für das Vertrauen in die Korrektheit verwenden, sollten Sie Standards festlegen, die auf der Zweigabdeckung oder Ähnlichem basieren.

Es gibt noch viele andere Metriken (die Zeilenabdeckung ähnelt der Anweisungsabdeckung, liefert aber bei mehrzeiligen Anweisungen andere numerische Ergebnisse; die bedingte Abdeckung und die Pfadabdeckung ähneln der Verzweigungsabdeckung, spiegeln aber eine detailliertere Sicht auf die möglichen Permutationen der Programmausführung wider, auf die man stoßen könnte).

Welcher Prozentsatz ist zu verlangen?

Abschließend möchte ich auf die ursprüngliche Frage zurückkommen: Wenn Sie Standards für die Codeabdeckung festlegen, wie hoch sollte diese Zahl sein?

Hoffentlich ist an dieser Stelle klar, dass es sich zunächst um eine Annäherung handelt, so dass jede Zahl, die wir wählen, von Natur aus eine Annäherung ist.

Einige Zahlen, die man wählen könnte:

• 100% . Vielleicht entscheiden Sie sich dafür, weil Sie sicher sein wollen, dass alles getestet wird. Dies gibt Ihnen keinen Einblick in die Qualität der Tests, aber es sagt Ihnen, dass ein Test von gewisser Qualität jede Anweisung (oder Verzweigung usw.) berührt hat: Wenn Ihre Testabdeckung unter 100% liegt, müssen Sie wissen eine Teilmenge Ihres Codes ist ungetestet.
  • Manche mögen einwenden, dass dies albern sei und man nur die Teile des Codes testen sollte, die wirklich wichtig sind. Ich würde argumentieren, dass man auch nur die Teile des Codes pflegen sollte, die wirklich wichtig sind. Die Codeabdeckung kann auch durch das Entfernen von ungetestetem Code verbessert werden.
• 99% (oder 95%, andere Zahlen in den hohen Neunzigern.) Geeignet in Fällen, in denen Sie ein Maß an Vertrauen vermitteln wollen ähnlich zu 100 %, aber lassen Sie sich einen gewissen Spielraum, damit Sie sich nicht über die eine oder andere schwer zu testende Ecke des Codes Sorgen machen müssen.
• 80% . Ich habe diese Nummer schon ein paar Mal gesehen und weiß nicht genau, woher sie stammt. I denken es könnte sich um eine seltsame Zweckentfremdung der 80-20-Regel handeln; im Allgemeinen geht es darum, zu zeigen, dass Die meisten Ihres Codes getestet wird. (Ja, 51 % wären auch "die meisten", aber 80 % entsprechen eher dem, was die meisten Menschen mittlere von den meisten.) Dies ist für mittlere Fälle geeignet, in denen "gut getestet" keine hohe Priorität hat (Sie wollen keine Mühe auf Tests mit geringem Wert verschwenden), aber eine ausreichende Priorität hat, so dass Sie trotzdem einen Standard haben möchten.

Ich habe in der Praxis noch keine Werte unter 80 % gesehen und kann mir nur schwer vorstellen, dass man sie festlegen sollte. Die Aufgabe dieser Standards ist es, das Vertrauen in die Korrektheit zu erhöhen, und Zahlen unter 80 % sind nicht besonders vertrauenserweckend. (Ja, das ist subjektiv, aber wie gesagt, die Idee ist, die subjektive Entscheidung einmal zu treffen, wenn man den Standard festlegt, und dann eine objektive Messung für die Zukunft zu verwenden).

Sonstige Anmerkungen

Die obigen Ausführungen gehen davon aus, dass Korrektheit das Ziel ist. Die Codeabdeckung ist nur eine Information; sie kann für andere Ziele relevant sein. Wenn Sie beispielsweise auf Wartbarkeit Wert legen, ist Ihnen wahrscheinlich eine lose Kopplung wichtig, die durch Testbarkeit nachgewiesen werden kann, die wiederum (auf bestimmte Art und Weise) durch Codeabdeckung gemessen werden kann. Ihr Codeabdeckungsstandard bietet also auch eine empirische Grundlage für die Annäherung an die Qualität der "Wartbarkeit".

Answer 4

Codeabdeckung ist gut, aber die Abdeckung der Funktionalität ist noch besser. Ich glaube nicht daran, jede einzelne Zeile, die ich schreibe, abzudecken. Aber ich glaube an eine 100%ige Testabdeckung aller Funktionen, die ich bereitstellen möchte (sogar für die besonders coolen Funktionen, die ich mir selbst ausgedacht habe und die in den Besprechungen nicht besprochen wurden).

Es ist mir egal, ob ich Code habe, der nicht durch Tests abgedeckt ist, aber es wäre mir nicht egal, wenn ich meinen Code umstrukturieren würde und am Ende ein anderes Verhalten hätte. Daher ist eine 100%ige Abdeckung der Funktionalität mein einziges Ziel.

Answer 5

Meine bevorzugte Codeabdeckung ist 100% mit einem Sternchen. Das Sternchen kommt daher, dass ich lieber Tools verwende, mit denen ich bestimmte Zeilen als "nicht zählend" markieren kann. Wenn ich 100 % der Zeilen, die "zählen", abgedeckt habe, bin ich fertig.

Der zugrunde liegende Prozess ist:

1. Ich schreibe meine Tests, um alle Funktionen und Randfälle zu testen, die mir einfallen (normalerweise anhand der Dokumentation).
2. Ich führe die Code Coverage Tools aus
3. Ich untersuche alle nicht abgedeckten Linien oder Pfade und markiere alle, die ich für unwichtig oder unerreichbar halte (aufgrund einer defensiven Programmierung), als nicht zählend.
4. Ich schreibe neue Tests, um die fehlenden Zeilen abzudecken, und verbessere die Dokumentation, wenn diese Randfälle nicht erwähnt sind.

Wenn ich und meine Mitarbeiter in Zukunft neuen Code hinzufügen oder die Tests ändern, gibt es eine klare Linie, die uns sagt, ob wir etwas Wichtiges übersehen haben - die Abdeckung ist unter 100 % gefallen. Es bietet aber auch die Flexibilität, mit unterschiedlichen Testprioritäten umzugehen.