it-swarm-eu.dev

Wie viel Code Coverage ist "genug"?

Wir starten hier bei meiner Arbeit einen Push für die Codeabdeckung, und ich muss darüber nachdenken ... Wie viel Codeabdeckung reicht aus?

Wann kommen Sie an den Punkt, an dem die Renditen der Codeabdeckung sinken? Was ist der Sweet Spot zwischen guter Abdeckung und nicht genug? Variiert es je nach Art des Projekts, das Sie erstellen (z. B. WPF, WCF, Mobile, ASP.NET) (Dies sind C # -Klassen, die wir schreiben.)

38
Vaccano

Wir streben mindestens 70% an. Bei Dingen, die leichter zu testen sind (z. B. funktionale Datenstrukturen), streben wir 90% an, und die meisten Personen streben so nahe wie möglich an 100% an. Bei WPF-bezogenen Dingen und anderen Frameworks, die sehr schwer zu testen sind, erhalten wir eine viel geringere Abdeckung (knapp 70%).

19
Noah Richards

Ich bin der Meinung, dass die Codeabdeckung allein eine schlechte Metrik ist. Es ist einfach, Tonnen von nutzlosen Tests zu erstellen, die den Code abdecken, aber die Ausgabe nicht angemessen überprüfen oder beispielsweise Edge-Fälle nicht testen. Das Abdecken von Code bedeutet nur, dass es keine Ausnahme auslöst, nicht dass es richtig ist. Sie brauchen Qualitätsprüfungen - die Quantität ist nicht so wichtig.

55
Fishtoaster

"Genug" ist, wenn Sie Änderungen an Ihrem Code vornehmen können, mit der Gewissheit, dass Sie nichts kaputt machen. Bei einigen Projekten sind dies möglicherweise 10%, bei anderen 95%.

Es ist fast nie so hoch wie 100%. Manchmal kann der Versuch, eine 100% ige Codeabdeckung zu erreichen, jedoch eine gute Möglichkeit sein, Cruft aus der Codebasis zu entfernen. Vergessen Sie nicht, dass es zwei Möglichkeiten gibt, die Codeabdeckung zu erhöhen: Schreiben Sie mehr Tests oder nehmen Sie Code heraus. Wenn Code nicht behandelt wird, weil er schwer zu testen ist, besteht eine gute Chance, dass Sie ihn vereinfachen oder umgestalten können, um das Testen zu vereinfachen. Wenn es zu dunkel ist, um es zu testen, besteht normalerweise eine gute Chance, dass nichts anderes im Code es verwendet.

38
RevBingo

Die Codeabdeckung nähert sich zu 100% asymptotisch. Folglich sind diese letzten 5% wahrscheinlich mehr Aufwand als es wert ist, da Sie anfangen, verschwindend kleine Renditen für den aufgewendeten Aufwand zu erzielen.

14
Robert Harvey

Die Abdeckung ist eine Metrik, die Sie im Auge behalten sollten, aber sie sollte nicht das ultimative Ziel sein. Ich habe viel Code mit hoher Abdeckung gesehen (und zugegebenermaßen geschrieben!) - 100% Abdeckung (TDD natürlich), aber:

  • es treten immer noch Fehler auf
  • design kann immer noch schlecht sein
  • sie können sich wirklich umbringen, indem Sie für ein beliebiges Deckungsziel schießen - wählen Sie Ihre Schlachten aus: p

Es gibt einen "Weg des Testivus" Eintrag , den ich für angebracht halte, um hier zu verweisen :)

7
H.Y.

Nur 20% des meisten Codes werden 80% der Zeit ausgeführt . Eine Codeabdeckungsanalyse ist nur dann sehr nützlich, wenn sie mit einem Aufrufdiagramm kombiniert wird, um zu bestimmen, was am meisten getestet werden muss. Das sagt Ihnen, wo Ihre Edge-Fälle wahrscheinlich sind. Sie können 100 Tests nur für die Edge-Fälle erstellen, die weniger als 5% des tatsächlichen Codes ausmachen.

Stellen Sie also sicher, dass 100% der 20%, die kritische Pfade definieren, und mindestens 50% der übrigen Pfade abgedeckt werden (gemäß Anrufdiagramm). Dies sollte Ihnen (ungefähr) 70% - 75% Gesamtabdeckung bringen, aber es variiert.

Verbrennen Sie keine Zeit damit, eine Gesamtabdeckung von über 70% zu erreichen, während Sie kritische Edge-Fälle ohne Überprüfungen belassen.

5
Tim Post

Verwenden Sie die Abdeckung als Richtlinie, um Bereiche anzuzeigen, die nicht getestet wurden. Anstatt ein Mandat für die Berichterstattung zu haben, ist es klüger, den Grund für den nicht abgedeckten Code zu verstehen. Das Aufzeichnen eines Grundes für das Defizit ist eine gute Disziplin, die es ermöglicht, die Risiken auszugleichen.

Manchmal ist der Grund weniger als wünschenswert, z. Die Zeit ist abgelaufen, könnte aber für eine vorzeitige Veröffentlichung in Ordnung sein. Es ist besser, Gebiete zu kennzeichnen, in die später zurückgekehrt werden soll, um die Abdeckung zu verbessern.

Ich arbeite an kritischer Flugsoftware, bei der eine 100% ige Abdeckung von Kontoauszügen für nicht kritische Systeme als geeignet angesehen wird. Für die kritischeren Systeme überprüfen wir die Zweigstellen-/Entscheidungsabdeckung und verwenden eine Technik namens MC/DC, die manchmal nicht streng genug ist.

Wir müssen auch sicherstellen, dass wir auch den Objektcode abgedeckt haben.

Es ist ein Gleichgewicht zwischen dem in unserem Fall sehr hohen Risiko und dem Wert/den Kosten. Eine fundierte Auswahl ist erforderlich, basierend auf dem Risiko, einen Fehler zu verpassen.

4
Mark Fisher

Wenn Sie Änderungen in Betracht ziehen, die sich auf die Laufzeitleistung, Sicherheit, Flexibilität oder Wartbarkeit auswirken, um mehr Codeabdeckung zu ermöglichen, ist es an der Zeit, die Suche nach mehr Codeabdeckung zu beenden.

Ich habe Projekte, bei denen dieser Punkt 0% beträgt, da die Abdeckung nicht berechnet werden kann, ohne das Design zu beeinträchtigen, und andere Projekte, bei denen dies bis zu 92% beträgt.

Kennzahlen zur Codeabdeckung sind nur nützlich, um darauf hinzuweisen, dass Sie möglicherweise einige Tests verpasst haben. Sie sagen Ihnen nichts über die Qualität Ihrer Tests.

3
Bill

Ich mag die Antwort von @ RevBingo sehr, weil er vorschlägt, dass der Kampf um 100% dazu führen kann, dass Sie nicht verwendeten Code bereinigen oder löschen. Was ich in den anderen Antworten nicht gesehen habe, ist ein Gefühl dafür, wann Sie eine hohe Abdeckung benötigen und wann nicht. Ich habe versucht, damit anzufangen. Ich denke, das Hinzufügen von Details zu einem Diagramm wie diesem wäre nützlicher, als eine Testabdeckungsnummer zu finden, die für den gesamten Code geeignet ist.

100%

Für eine öffentliche API wie die Java.util-Sammlungen, die nicht an eine Datenbank gekoppelt ist und kein HTML zurückgibt, halte ich eine 100% ige Abdeckung für ein gutes Startziel, selbst wenn Sie sich aus zeitlichen oder anderen Gründen mit 90-95% zufrieden geben Einschränkungen. Das Erhöhen der Testabdeckung nach Abschluss der Funktion erzwingt eine detailliertere Prüfung als andere Arten der Codeüberprüfung. Wenn Ihre API überhaupt beliebt ist, wird sie von Benutzern verwendet, in Unterklassen unterteilt, deserialisiert usw. auf eine Weise, die Sie nicht erwarten können. Sie möchten nicht, dass ihre erste Erfahrung darin besteht, einen Fehler zu finden oder das Design zu übersehen!

90%

Für Geschäftsinfrastrukturcode, der Datenstrukturen aufnimmt und Datenstrukturen zurückgibt, sind 100% wahrscheinlich immer noch ein gutes Startziel. Wenn dieser Code jedoch nicht öffentlich genug ist, um viel Missbrauch einzuladen, sind 85% möglicherweise noch akzeptabel?

75%

Für Code, der Strings aufnimmt und zurückgibt, denke ich, dass Unit-Tests viel spröder sind, aber in vielen Situationen immer noch nützlich sein können.

50% oder weniger

Ich hasse es, Tests für Funktionen zu schreiben, die HTML zurückgeben, weil es so spröde ist. Was ist, wenn jemand das CSS, das JavaScript oder den gesamten HTML- und Englisch-Blob ändert, den Sie zurückgeben, was für menschliche Endbenutzer keinen Sinn ergibt? Wenn Sie eine Funktion finden, die viel Geschäftslogik verwendet, um ein wenig HTML zu erstellen, ist dies möglicherweise einen Test wert. Aber die umgekehrte Situation ist möglicherweise überhaupt nicht testenswert.

Nahezu 0%

Für einige Codes lautet die Definition von "richtig" "für den Endbenutzer sinnvoll". Es gibt nicht traditionelle Tests, die Sie mit diesem Code durchführen können, z. B. automatisierte Grammatikprüfung oder HTML-Validierung der Ausgabe. Ich habe sogar grep-Anweisungen für kleine Inkonsistenzen eingerichtet, denen wir bei der Arbeit normalerweise zum Opfer fallen, z. B. "Anmelden", wenn der Rest des Systems es "Anmelden" nennt. Dieser Mann ist nicht unbedingt ein Komponententest, sondern eine hilfreiche Methode, um Probleme zu erkennen, ohne eine bestimmte Ausgabe zu erwarten.

Letztendlich kann jedoch nur ein Mensch beurteilen, was für den Menschen sinnvoll ist. Unit-Tests können Ihnen dort nicht helfen. Manchmal braucht es mehrere Menschen, um das genau zu beurteilen.

Absolut 0%

Dies ist eine traurige Kategorie und ich fühle mich weniger als eine Person, die sie schreibt. Aber in jedem ausreichend großen Projekt gibt es Kaninchenlöcher, die Wochen in Anspruch nehmen können, ohne einen geschäftlichen Nutzen zu bringen.

Ich habe ein Buch gekauft, weil es angeblich zeigt, wie Daten zum Testen von Hibernate automatisch verspottet werden. Es wurden jedoch nur Hibernate HQL- und SQL-Abfragen getestet. Wenn Sie viel HQL und SQL ausführen müssen, erhalten Sie den Vorteil von Hibernate nicht wirklich. Es gibt eine Form von Hibernate-In-Memory-Datenbank, aber ich habe nicht die Zeit investiert, um herauszufinden, wie man sie effektiv in Tests verwendet. Wenn ich das ausführen würde, würde ich eine hohe Testabdeckung (50% -100%) für jede Geschäftslogik wünschen, die Dinge durch Navigieren in einem Objektdiagramm berechnet, wodurch Hibernate einige Abfragen ausführt. Meine Fähigkeit, diesen Code zu testen, liegt derzeit bei 0%, und das ist ein Problem. Daher verbessere ich die Testabdeckung in anderen Bereichen des Projekts und versuche, reine Funktionen denen vorzuziehen, die auf die Datenbank zugreifen, hauptsächlich weil es einfacher ist, Tests für diese Funktionen zu schreiben. Dennoch können oder sollten einige Dinge nicht getestet werden.

2
GlenPeterson

Platzkritische Software erfordert eine 100% ige Abdeckung von Anweisungen.

Zunächst macht es keinen Sinn. Jeder weiß, dass eine vollständige Testabdeckung nicht bedeutet, dass der Code vollständig getestet wurde und dass es nicht so schwierig ist, eine 100% ige Abdeckung zu erhalten, ohne die Anwendung tatsächlich zu testen.

Trotzdem ist eine 100% ige Abdeckung eine Untergrenze: Obwohl eine 100% ige Abdeckung kein Beweis für eine fehlerfreie Software ist, ist es sicher, dass der Code bei einer geringeren Abdeckung nicht vollständig getestet wird und dies für platzkritische Software einfach nicht akzeptabel ist.

2
mouviciel

Ich denke, es hängt von dem Teil der Anwendung ab, den Sie testen. Z.B. Für Geschäftslogik oder Komponenten mit komplexen Datentransformationen würde ich eine Abdeckung von 90% (so hoch wie möglich) anstreben. Ich habe oft kleine, aber gefährliche Fehler gefunden, indem ich nur so viel Code wie möglich getestet habe. Ich würde solche Fehler lieber beim Testen finden, als sie ein Jahr später bei einem Kunden auftreten zu lassen. Ein Vorteil einer hohen Codeabdeckung besteht auch darin, dass verhindert wird, dass Personen den Arbeitscode zu leicht ändern, da die Tests entsprechend angepasst werden müssen.

Andererseits denke ich, dass es Komponenten gibt, für die die Codeabdeckung weniger geeignet ist. Wenn Sie beispielsweise eine GUI testen, ist es sehr zeitaufwändig, einen Test zu schreiben, der den gesamten Code abdeckt, der beim Klicken auf eine Schaltfläche ausgeführt wird, um das Ereignis an die richtigen Komponenten zu senden. Ich denke, in diesem Fall ist es viel effektiver, den traditionellen Ansatz der Durchführung eines manuellen Tests zu verwenden, bei dem Sie einfach auf die Schaltfläche klicken und das Verhalten des Programms beobachten (öffnet sich das richtige Dialogfenster? Wird das richtige Werkzeug ausgewählt?) ?).

1
Giorgio

Ich habe keine so hohe Meinung über die Verwendung der Codeabdeckung als Maß dafür, wann Ihre Testsuite über eine ausreichende Abdeckung verfügt.

Der Hauptgrund dafür ist, dass wenn Sie einen Prozess haben, in dem Sie zuerst Code schreiben, dann einige Tests durchführen und dann anhand der Codeabdeckung feststellen, wo Sie einen Test verpasst haben, dieser Prozess verbessert werden muss. Wenn Sie echte TDD ausführen, ist die Codeabdeckung zu 100% sofort einsatzbereit (zugegebenermaßen gibt es einige Kleinigkeiten, auf die ich nicht teste). Wenn Sie sich jedoch die Codeabdeckung ansehen, um herauszufinden, was getestet werden soll, werden Sie wahrscheinlich die falschen Tests schreiben.

Das einzige, was Sie aus der Codeabdeckung schließen können, ist, dass Sie nicht genügend Tests haben, wenn sie zu niedrig ist. Wenn es jedoch hoch ist, gibt es keine Garantie dafür, dass Sie die richtigen Tests haben.

0
Pete