Wenn Sie eine minimale prozentuale Codeabdeckung für Komponententests vorschreiben würden, möglicherweise sogar als Voraussetzung für das Festschreiben an ein Repository, welche wäre das?

Bitte erläutern Sie, wie Sie zu Ihrer Antwort gekommen sind (denn wenn Sie nur eine Nummer ausgewählt hätten, hätte ich das ganz alleine tun können;)

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

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

Testivus über Testabdeckung

Eines frühen Morgens fragte ein Programmierer den großen Meister:

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

Der große Meister antwortete:

"Mach dir keine Sorgen um die Berichterstattung, schreibe einfach ein paar gute Tests."

Der Programmierer lächelte, verbeugte sich und ging.

...

Später an diesem Tag stellte ein zweiter Programmierer dieselbe Frage.

Der große Meister zeigte auf einen Topf mit kochendem Wasser und sagte:

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

Der Programmierer sah verwirrt aus und antwortete:

„Wie kann ich es dir möglicherweise sagen? Es hängt davon ab, wie viele Menschen Sie füttern müssen, wie hungrig sie sind, welche anderen Lebensmittel 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 stellte dieselbe Frage zur Codeabdeckung.

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

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

...

Nach dieser letzten Antwort trat ein junger Lehrling an den großen Meister heran:

„Großer Meister, heute habe ich gehört, dass Sie dieselbe Frage zur Codeabdeckung mit drei verschiedenen Antworten beantworten. Warum?"

Der große Meister stand von seinem Stuhl auf:

"Komm, hol mir frischen Tee und lass uns darüber reden."

Nachdem sie ihre Tassen mit heißem grünem Tee gefüllt hatten, begann der große Meister zu antworten:

„Der erste Programmierer ist neu und beginnt gerade mit dem Testen. Im Moment hat er viel Code und keine Tests. Er hat noch einen langen Weg vor sich; Die Konzentration auf die Codeabdeckung zu diesem Zeitpunkt wäre deprimierend und völlig nutzlos. Er ist besser dran, sich nur daran zu gewöhnen, einige Tests zu schreiben und durchzuführen. Er kann sich später um die Berichterstattung kümmern. “

„Der zweite Programmierer hingegen hat sowohl Erfahrung im Programmieren als auch im Testen. Als ich sie fragte, wie viele Reiskörner ich in einen Topf geben sollte, half ich ihr zu erkennen, dass die Menge der erforderlichen Tests von einer Reihe von Faktoren abhängt, und sie kennt diese Faktoren besser als ich - es ist schließlich ihr Code . Es gibt keine einfache Antwort, und sie ist klug genug, um mit der Wahrheit umzugehen und damit zu arbeiten. “

"Ich verstehe", sagte der junge Lehrling, "aber wenn es keine einfache Antwort gibt, warum haben Sie dann dem dritten Programmierer 'Achtzig Prozent und nicht weniger' geantwortet?"

Der große Meister lachte so heftig und laut, dass sein Bauch, ein Beweis dafür, dass er mehr als nur grünen Tee trank, auf und ab flatterte.

"Der dritte Programmierer möchte nur einfache Antworten - auch wenn es keine einfachen Antworten gibt ... und folgt ihnen dann sowieso nicht."

Der junge Lehrling und der grizzled große Meister tranken ihren Tee in nachdenklicher Stille.

Die Codeabdeckung ist eine irreführende Messgröße, wenn eine 100% ige Abdeckung Ihr Ziel ist (anstatt alle Funktionen zu 100% zu testen).

• Sie könnten 100% erreichen, wenn Sie alle Zeilen einmal treffen. Sie könnten jedoch immer noch das Testen einer bestimmten Sequenz (logischer Pfad) verpassen, in der diese Zeilen getroffen werden.
• Sie konnten keine 100% erhalten, haben aber dennoch alle Ihre 80% / Frequenz verwendeten Codepfade getestet. Tests zu haben, die jeden 'Throw ExceptionTypeX' oder einen ähnlichen defensiven Programmierschutz testen, den Sie eingesetzt haben, ist ein 'nice to have' und kein 'must have'.

Vertrauen Sie sich selbst oder Ihren Entwicklern, dass sie gründlich sind und jeden Pfad durch ihren Code abdecken. Seien Sie pragmatisch und jagen Sie nicht der magischen 100% igen Abdeckung nach. Wenn Sie Ihren Code TDD, sollten Sie eine 90% + Deckung als Bonus erhalten. Verwenden Sie die Codeabdeckung, um verpasste Codestücke hervorzuheben (sollte jedoch nicht passieren, wenn Sie TDD verwenden. Da Sie Code nur schreiben, um einen Test zu bestehen. Ohne den Partnertest kann kein Code vorhanden sein.)

Die Codeabdeckung ist großartig, aber die Funktionsabdeckung ist noch besser. Ich glaube nicht daran, jede einzelne Zeile abzudecken, die ich schreibe. Ich glaube jedoch daran, eine 100% ige Testabdeckung aller Funktionen zu schreiben, die ich bereitstellen möchte (selbst für die besonders coolen Funktionen, die ich selbst mitgebracht habe und die während der Besprechungen nicht besprochen wurden).

Es ist mir egal, ob ich Code hätte, der nicht in Tests behandelt wird, aber es wäre mir wichtig, wenn ich meinen Code umgestalten und am Ende ein anderes Verhalten haben würde. Daher ist eine 100% ige Funktionsabdeckung mein einziges Ziel.

Die akzeptierte Antwort macht einen guten Punkt - es gibt keine einzige Zahl, die als Standard für jedes Projekt sinnvoll ist. Es gibt Projekte, die einen solchen Standard einfach nicht benötigen. Wenn die akzeptierte Antwort meiner Meinung nach nicht ausreicht, wird beschrieben, wie man diese Entscheidung für ein bestimmtes Projekt treffen kann.

Ich werde es versuchen. Ich bin kein Experte für Testtechnik und würde mich über eine fundiertere Antwort freuen.

Wann müssen die Anforderungen an die Codeabdeckung festgelegt werden?

Erstens, warum sollten Sie überhaupt einen solchen Standard auferlegen wollen? Im Allgemeinen, wenn Sie empirisches Vertrauen in Ihren Prozess schaffen möchten. Was meine ich mit "empirischem Vertrauen"? Nun, die wahre Zielkorrektheit . Bei den meisten Programmen können wir dies möglicherweise nicht über alle Eingaben hinweg wissen. Daher geben wir an, dass der Code gut getestet ist . Dies ist besser bekannt, aber immer noch ein subjektiver Standard: Es wird immer offen sein, darüber zu diskutieren, ob Sie ihn erfüllt haben oder nicht. Diese Debatten sind nützlich und sollten stattfinden, aber sie bringen auch Unsicherheit mit sich.

Die Codeabdeckung ist eine objektive Messung: Sobald Sie Ihren Abdeckungsbericht sehen, besteht keine Unklarheit darüber, ob Standards erfüllt wurden, die nützlich sind. Beweist es die Richtigkeit? Überhaupt nicht, aber es hat eine klare Beziehung dazu, wie gut der Code getestet wurde, was wiederum unser bester Weg ist, um das Vertrauen in seine Richtigkeit zu erhöhen. Die Codeabdeckung ist eine messbare Annäherung an unermessliche Eigenschaften, die uns wichtig sind.

Einige spezielle Fälle, in denen ein empirischer Standard einen Mehrwert bieten könnte:

• Stakeholder zufrieden stellen. Für viele Projekte gibt es verschiedene Akteure, die ein Interesse an Softwarequalität haben und möglicherweise nicht an der täglichen Entwicklung der Software beteiligt sind (Manager, technische Leiter usw.). Sie sagen: "Wir werden alle schreiben." Tests, die wir wirklich brauchen "sind nicht überzeugend: Sie müssen entweder vollständig vertrauen oder mit ständiger Kontrolle überprüfen (vorausgesetzt, sie verfügen sogar über das technische Verständnis dafür). Es ist besser, messbare Standards bereitzustellen und zu erklären, wie sie sich den tatsächlichen Zielen angemessen annähern.
• Teamverhalten normalisieren. Abgesehen von den Stakeholdern besteht bei der Arbeit in einem Team, in dem mehrere Personen Code und Tests schreiben, Raum für Unklarheiten darüber, was als "gut getestet" eingestuft wird. Haben alle Ihre Kollegen die gleiche Vorstellung davon, welches Testniveau gut genug ist? Wahrscheinlich nicht. Wie vereinbaren Sie das? Finden Sie eine Metrik, auf die Sie sich alle einigen können, und akzeptieren Sie sie als vernünftige Annäherung. Dies ist besonders (aber nicht ausschließlich) in großen Teams nützlich, in denen Leads beispielsweise möglicherweise keine direkte Kontrolle über Junior-Entwickler haben. Vertrauensnetzwerke sind ebenfalls wichtig, aber ohne objektive Messungen kann das Verhalten von Gruppen leicht inkonsistent werden, selbst wenn alle in gutem Glauben handeln.
• Um ehrlich zu sein. Selbst wenn Sie der einzige Entwickler und einzige Stakeholder für Ihr Projekt sind, haben Sie möglicherweise bestimmte Eigenschaften für die Software im Auge. Anstatt fortlaufend subjektive Bewertungen darüber vorzunehmen, wie gut die Software getestet wurde (was Arbeit erfordert), können Sie die Codeabdeckung als vernünftige Annäherung verwenden und von Maschinen für Sie messen lassen.

Welche Metriken sollen verwendet werden?

Die Codeabdeckung ist keine einzelne Metrik. Es gibt verschiedene Möglichkeiten, die Abdeckung zu messen. Welchen Sie einen Standard setzen könnten, hängt davon ab, was Sie mit diesem Standard erfüllen.

Ich werde zwei gängige Metriken als Beispiele dafür verwenden, wann Sie sie zum Festlegen von Standards verwenden könnten:

• Anweisungsabdeckung : Wie viel Prozent der Anweisungen wurden während des Tests ausgeführt? Nützlich, um ein Gefühl für die physische Abdeckung Ihres Codes zu bekommen: Wie viel von dem Code, den ich geschrieben habe, habe ich tatsächlich getestet?
  • Diese Art der Berichterstattung unterstützt ein schwächeres Argument der Korrektheit, ist aber auch leichter zu erreichen. Wenn Sie nur die Codeabdeckung verwenden, um sicherzustellen, dass die Dinge getestet werden (und nicht als Indikator für die darüber hinausgehende Testqualität), ist die Anweisungsabdeckung wahrscheinlich ausreichend.
• Zweigabdeckung : Wurden ifbeide Zweige ausgewertet, wenn eine Verzweigungslogik (z. B. eine ) vorhanden ist? Dies gibt einen besseren Überblick über die logische Abdeckung Ihres Codes: Wie viele der möglichen Pfade, die mein Code einschlagen kann, habe ich getestet?
  • Diese Art der Abdeckung ist ein viel besserer Indikator dafür, dass ein Programm über einen umfassenden Satz von Eingaben getestet wurde. Wenn Sie die Codeabdeckung als beste empirische Annäherung für das Vertrauen in die Korrektheit verwenden, sollten Sie Standards festlegen, die auf der Zweigabdeckung oder ähnlichem basieren.

Es gibt viele andere Metriken (die Zeilenabdeckung ähnelt der Anweisungsabdeckung, liefert jedoch unterschiedliche numerische Ergebnisse für mehrzeilige Anweisungen, die bedingte Abdeckung und die Pfadabdeckung ähneln der Zweigabdeckung, spiegeln jedoch eine detailliertere Ansicht der möglichen Permutationen von wider Programmausführung, auf die Sie möglicherweise stoßen.)

Welchen Prozentsatz benötigen

Zurück zur ursprünglichen Frage: 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, sodass jede Zahl, die wir auswählen, von Natur aus ungefähr ist.

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

• 100% . Sie können dies wählen, weil Sie sicher sein möchten, dass alles getestet wird. Dies gibt Ihnen keinen Einblick in die Testqualität, sagt Ihnen jedoch, dass ein Test mit einer bestimmten Qualität jede Aussage (oder jeden Zweig usw.) berührt hat. Dies führt wiederum zu einem gewissen Grad an Vertrauen zurück: Wenn Ihre Abdeckung unter 100% liegt Sie wissen , dass eine Teilmenge Ihres Codes nicht getestet wurde.
  • Einige mögen argumentieren, dass dies albern ist, und Sie sollten nur die Teile Ihres Codes testen, die wirklich wichtig sind. Ich würde argumentieren, dass Sie auch nur die Teile Ihres Codes pflegen sollten, die wirklich wichtig sind. Die Codeabdeckung kann verbessert werden, indem auch nicht getesteter Code entfernt wird.
• 99% (oder 95%, andere Zahlen in den hohen neunziger Jahre.) Angemessen in Fällen , in denen Sie ein Maß an Vertrauen vermitteln wollen ähnlich zu 100%, aber lassen Sie sich etwas Spielraum , um sich keine Sorgen über die gelegentlichen schwer zu Test Ecke Code.
• 80% . Ich habe diese Nummer einige Male in Gebrauch gesehen und weiß nicht ganz, woher sie stammt. Ich denke, es könnte eine seltsame Veruntreuung der 80-20-Regel sein; Im Allgemeinen soll hier gezeigt werden, dass der größte Teil Ihres Codes getestet wird. (Ja, 51% wären auch "am meisten", aber 80% spiegeln besser wider, was die meisten Menschen mit den meisten meinen .) Dies ist für Fälle mit mittlerem Hintergrund geeignet, in denen "gut getestet" keine hohe Priorität hat (Sie tun es nicht). Sie möchten keine Mühe mit Tests mit geringem Wert verschwenden. Dies ist jedoch eine Priorität, für die Sie immer noch einen Standard haben möchten.

Ich habe in der Praxis keine Zahlen unter 80% gesehen und es fällt mir schwer, mir einen Fall vorzustellen, in dem man sie einstellen würde. Die Rolle dieser Standards besteht darin, das Vertrauen in die Korrektheit zu stärken, und Zahlen unter 80% sind nicht besonders vertrauensinspirierend. (Ja, dies ist subjektiv, aber auch hier besteht die Idee darin, die subjektive Wahl einmal zu treffen, wenn Sie den Standard festlegen, und dann in Zukunft eine objektive Messung durchzuführen.)

Weitere Hinweise

Das Obige setzt voraus, dass Korrektheit das Ziel ist. Codeabdeckung ist nur Information; es kann für andere Ziele relevant sein. Wenn Sie sich beispielsweise Gedanken über die Wartbarkeit machen, interessieren Sie sich wahrscheinlich für eine lose Kopplung, die durch Testbarkeit demonstriert werden kann, die wiederum (auf bestimmte Weise) durch Codeabdeckung gemessen werden kann. Ihr Code-Coverage-Standard bietet daher eine empirische Grundlage für die Annäherung an die Qualität der "Wartbarkeit".

Meine Lieblingscodeabdeckung ist 100% mit einem Sternchen. Das Sternchen kommt, weil ich lieber Werkzeuge verwende, mit denen ich bestimmte Zeilen als Zeilen markieren kann, die "nicht zählen". Wenn ich 100% der Zeilen abgedeckt habe, die "zählen", bin ich fertig.

Der zugrunde liegende Prozess ist:

1. Ich schreibe meine Tests, um alle Funktionen und Randfälle auszuüben, die mir einfallen (normalerweise anhand der Dokumentation).
2. Ich führe die Tools zur Codeabdeckung aus
3. Ich untersuche alle Linien oder Pfade, die nicht abgedeckt sind, und alle, die ich für nicht wichtig oder unerreichbar halte (aufgrund defensiver Programmierung), die ich als nicht zählend markiere
4. Ich schreibe neue Tests, um die fehlenden Zeilen abzudecken und die Dokumentation zu verbessern, wenn diese Randfälle nicht erwähnt werden.

Auf diese Weise gibt es eine helle Linie, wenn wir und meine Mitarbeiter in Zukunft neuen Code hinzufügen oder die Tests ändern, wenn wir etwas Wichtiges verpasst haben - die Abdeckung ist unter 100% gefallen. Es bietet jedoch auch die Flexibilität, mit unterschiedlichen Testprioritäten umzugehen.

Ich hätte eine weitere Anektode zur Testabdeckung, die ich teilen möchte.

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

Scott Hanselman antwortete mit Worten der Weisheit :

Ist es die richtigen 20%? Sind es die 20%, die den Code darstellen, den Ihre Benutzer am meisten getroffen haben? Sie können 50 weitere Tests hinzufügen und nur 2% hinzufügen.

Wieder geht es zurück zu meinem Testivus auf Code Coverage Answer. Wie viel Reis solltest du in den Topf geben? Es hängt davon ab, ob.

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 sind. Kleine Klassen, die testbar sein sollen, sollten nicht schwer besser abzudecken sein.

Es ist einfach, diese Frage mit etwas wie:

• Abgedeckte Zeilen entsprechen nicht der getesteten Logik und man sollte nicht zu viel in den Prozentsatz einlesen.

Es stimmt, aber es gibt einige wichtige Punkte zur Codeabdeckung. Nach meiner Erfahrung ist diese Metrik bei richtiger Verwendung tatsächlich sehr nützlich. Trotzdem habe ich nicht alle Systeme gesehen, und ich bin sicher, dass es Unmengen von Systemen gibt, bei denen es schwierig ist, eine Analyse der Codeabdeckung zu sehen, die einen echten Mehrwert bietet. Code kann so unterschiedlich aussehen und der Umfang des verfügbaren Testframeworks kann variieren.

Außerdem betrifft meine Argumentation hauptsächlich ziemlich kurze Test-Feedback-Schleifen. Für das Produkt, das ich entwickle, ist die kürzeste Rückkopplungsschleife sehr flexibel und deckt alles ab, von Klassentests bis hin zur Signalisierung zwischen Prozessen. Das Testen eines lieferbaren Unterprodukts dauert in der Regel 5 Minuten. Für eine so kurze Rückkopplungsschleife ist es tatsächlich möglich, die Testergebnisse (und insbesondere die hier betrachtete Metrik für die Codeabdeckung) zu verwenden, um Commits im Repository abzulehnen oder zu akzeptieren.

Wenn Sie die Codeabdeckungsmetrik verwenden, sollten Sie nicht nur einen festen (willkürlichen) Prozentsatz haben, der erfüllt sein muss. Wenn Sie dies tun, erhalten Sie meiner Meinung nach nicht die wirklichen Vorteile einer Analyse der Codeabdeckung. Definieren Sie stattdessen die folgenden Metriken:

• Low Water Mark (LWM), die niedrigste Anzahl unbedeckter Linien, die jemals im getesteten System gesehen wurden
• High Water Mark (HWM), der höchste Prozentsatz der Codeabdeckung, der jemals für das zu testende System ermittelt wurde

Neuer Code kann nur hinzugefügt werden, wenn wir das LWM nicht überschreiten und das HWM nicht unterschreiten. Mit anderen Worten, die Codeabdeckung darf nicht abnehmen , und neuer Code sollte abgedeckt werden. Beachten Sie, wie ich sagen sollte und nicht muss (unten erklärt).

Aber heißt das nicht, dass es unmöglich sein wird, alten, bewährten Müll zu beseitigen, für den Sie keine Verwendung mehr haben? 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 tägliche Integration habe ich die Erfahrung gemacht, dass diese Metriken sehr nützlich sind. Sie geben 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, alles mit Ihren Testfällen abzudecken. Testbarer Code ist normalerweise eine gute Sache.

• Die Testabdeckung für Legacy-Code nimmt mit der Zeit zu. Wenn Sie neuen Code hinzufügen und ihn nicht mit einem Testfall abdecken können, können Sie versuchen, stattdessen älteren Code zu behandeln, um die LWM-Regel zu umgehen. Dieses manchmal notwendige Betrügen führt zumindest zu dem positiven Nebeneffekt, dass die Abdeckung von Legacy-Code mit der Zeit zunimmt, was die scheinbar strikte Durchsetzung dieser Regeln in der Praxis recht pragmatisch macht.

Und wieder, wenn die Rückkopplungsschleife zu lang ist, kann es völlig unpraktisch sein, so etwas im Integrationsprozess einzurichten.

Ich möchte auch zwei allgemeinere Vorteile der Code-Coverage-Metrik erwähnen.

• Die Codeabdeckungsanalyse ist Teil der dynamischen Codeanalyse (im Gegensatz zur statischen, dh Lint). Probleme, die während der dynamischen Codeanalyse auftreten (mithilfe von Tools wie der Purify-Familie, http://www-03.ibm.com/software/products/en/rational-purify-family ), sind beispielsweise nicht initialisierte Speicherlesevorgänge (UMR). Speicherlecks usw. Diese Probleme können nur gefunden werden, wenn der Code von einem ausgeführten Testfall abgedeckt wird . Der Code, der in einem Testfall am schwierigsten zu behandeln ist, sind normalerweise die abnormalen Fälle im System. Wenn Sie jedoch möchten, dass das System ordnungsgemäß ausfällt (dh Fehlersuche anstelle eines Absturzes), sollten Sie einige Anstrengungen unternehmen, um die abnormalen Fälle abzudecken auch in der dynamischen Code-Analyse. Mit ein bisschen Pech kann ein UMR zu einem Segfault oder Schlimmerem führen.

• Die Leute sind stolz darauf, 100% für neuen Code zu behalten, und die Leute diskutieren Testprobleme mit einer ähnlichen Leidenschaft wie andere Implementierungsprobleme. Wie kann diese Funktion testbarer geschrieben werden? Wie würden Sie versuchen, diesen abnormalen Fall usw. abzudecken?

Und der Vollständigkeit halber ein Negativ.

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

Wenn dies eine perfekte Welt wäre, würden 100% des Codes durch Unit-Tests abgedeckt. Da dies jedoch KEINE perfekte Welt ist, kommt es darauf an, wofür Sie Zeit haben. Aus diesem Grund empfehle ich, sich weniger auf einen bestimmten Prozentsatz und mehr auf die kritischen Bereiche zu konzentrieren. Wenn Ihr Code gut geschrieben ist (oder zumindest ein vernünftiges Faksimile davon), sollte es mehrere wichtige Punkte geben, an denen APIs anderem Code ausgesetzt sind.

Konzentrieren Sie Ihre Testbemühungen auf diese APIs. Stellen Sie sicher, dass die APIs 1) gut dokumentiert sind und 2) Testfälle geschrieben haben, die mit der Dokumentation übereinstimmen. Wenn die erwarteten Ergebnisse nicht mit den Dokumenten übereinstimmen, liegt ein Fehler in Code, Dokumentation oder Testfällen vor. All das ist gut zum Auschecken.

Viel Glück!

Viele Geschäfte bewerten Tests nicht. Wenn Sie also zumindest über Null sind, gibt es eine gewisse Wertsteigerung - also ist Nicht-Null wohl nicht schlecht, da viele immer noch Null sind.

In der .Net-Welt zitieren die Leute oft 80% als vernünftig. Aber sie sagen dies auf Lösungsebene. Ich ziehe es vor, auf Projektebene zu messen: 30% sind möglicherweise gut für UI-Projekte, wenn Sie Selen usw. oder manuelle Tests haben, 20% für das Datenschichtprojekt sind möglicherweise in Ordnung, aber 95% + sind für das Unternehmen durchaus erreichbar Regelschicht, wenn 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: Streben Sie nach 100% und Sie werden 80% erreichen; aber strebe 80% an und du wirst 40% erreichen.

Fazit: Wenden Sie die 80: 20-Regel an und lassen Sie sich von der Fehleranzahl Ihrer App leiten.

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

85% wären ein guter Ausgangspunkt für Check-in-Kriterien.

Ich würde wahrscheinlich eine Reihe höherer Balken als Versandkriterien wählen - abhängig von der Kritikalität der zu testenden Subsysteme / Komponenten.

Ich verwende Cobertura, und unabhängig vom Prozentsatz würde ich empfehlen, die Werte in der Cobertura-Check-Aufgabe auf dem neuesten Stand zu halten. Erhöhen Sie mindestens die Gesamtmenge und die Gesamtverzweigung auf knapp unter Ihre aktuelle Abdeckung, aber senken Sie diese Werte niemals . Verknüpfen Sie auch die Eigenschaft Ant Build Failure mit dieser Aufgabe. Wenn der Build aufgrund mangelnder Abdeckung fehlschlägt, kennen Sie den hinzugefügten Code einer Person, haben ihn jedoch nicht getestet. Beispiel:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Wenn ich denke, dass mein Code nicht genug Unit-getestet ist und ich nicht sicher bin, was ich als nächstes testen soll, verwende ich die Abdeckung, um zu entscheiden, was als nächstes getestet werden soll.

Wenn ich die Abdeckung in einem Unit-Test erhöhe, weiß ich, dass dieser Unit-Test etwas wert ist.

Dies gilt für Code, der nicht, zu 50% oder zu 97% abgedeckt ist.

Ich bevorzuge BDD, bei dem eine Kombination aus automatisierten Abnahmetests, möglicherweise anderen Integrationstests und Komponententests verwendet wird. Die Frage für mich ist, wie die Zielabdeckung der gesamten automatisierten Testsuite aussehen soll.

Abgesehen davon hängt die Antwort von Ihrer Methodik, Sprache sowie den Test- und Berichterstattungstools ab. Wenn Sie TDD in Ruby oder Python ausführen, ist es nicht schwer, eine 100% ige Abdeckung aufrechtzuerhalten, und es lohnt sich, dies zu tun. Es ist viel einfacher, eine 100% ige Abdeckung zu verwalten als eine 90-prozentige Abdeckung.Das heißt, es ist viel einfacher, Deckungslücken so zu füllen, wie sie erscheinen (und wenn Sie TDD-Bohrlöcher gut abdecken, sind Deckungslücken selten und normalerweise Ihre Zeit wert), als eine Liste von Deckungslücken zu verwalten, zu denen Sie nicht gekommen sind, und die Deckung zu verpassen Regressionen aufgrund Ihres ständigen Hintergrunds von ungedecktem Code.

Die Antwort hängt auch von der Geschichte Ihres Projekts ab. Ich habe das oben Genannte nur in Projekten gefunden, die von Anfang an so verwaltet wurden. Ich habe die Abdeckung großer Legacy-Projekte erheblich verbessert, und es hat sich gelohnt, dies zu tun, aber ich habe es nie als praktisch empfunden, zurück zu gehen und jede Abdeckungslücke zu schließen, da alter, nicht getesteter Code nicht gut genug verstanden wird, um dies korrekt und korrekt zu tun schnell.

Wenn Sie eine anständige Zeit lang Unit-Tests durchgeführt haben, sehe ich keinen Grund dafür, sich 95% + nicht zu nähern. Zumindest habe ich jedoch immer mit 80% gearbeitet, auch wenn ich neu im Testen war.

Diese Nummer sollte nur im Projekt geschriebenen Code enthalten (ausgenommen Frameworks, Plugins usw.) und möglicherweise sogar bestimmte Klassen ausschließen, die vollständig aus Code bestehen, der aus Aufrufen von externem Code besteht. Diese Art von Anruf sollte verspottet / gestoppt werden.

Im Allgemeinen ist aus den verschiedenen von mir gelesenen Best Practices-Papieren zu technischen Spitzenleistungen 80% für neuen Code in Komponententests der Punkt, der die beste Rendite erzielt. Ein Überschreiten dieses CC% ergibt eine geringere Anzahl von Fehlern für den Aufwand. Dies ist eine bewährte Methode, die von vielen großen Unternehmen verwendet wird.

Leider sind die meisten dieser Ergebnisse unternehmensintern, so dass es keine öffentlichen Literaturen gibt, auf die ich Sie hinweisen kann.

Die Codeabdeckung ist großartig, aber nur solange die Vorteile, die Sie daraus ziehen, die Kosten / den Aufwand dafür überwiegen.

Wir arbeiten seit einiger Zeit an einem Standard von 80%, haben jedoch gerade die Entscheidung getroffen, dies aufzugeben und uns stattdessen mehr auf unsere Tests zu konzentrieren. Konzentration auf die komplexe Geschäftslogik usw.

Diese Entscheidung wurde aufgrund der zunehmenden Zeit getroffen, die wir für die Verfolgung der Codeabdeckung und die Wartung bestehender Komponententests aufgewendet haben. Wir hatten das Gefühl, dass wir an einem Punkt angelangt waren, an dem der Nutzen, den wir aus unserer Codeabdeckung ziehen, als geringer angesehen wurde als der Aufwand, den wir investieren mussten, um dies zu erreichen.

Kurze Antwort: 60-80%

Lange Antwort: Ich denke, es hängt ganz von der Art Ihres Projekts ab. Normalerweise starte ich ein Projekt, indem ich jedes praktische Stück testweise teste. Bei der ersten "Veröffentlichung" des Projekts sollten Sie einen ziemlich guten Basisprozentsatz haben, der auf der Art der Programmierung basiert, die Sie ausführen. An diesem Punkt können Sie damit beginnen, eine minimale Codeabdeckung zu "erzwingen".

Schauen Sie sich Crap4j an . Es ist ein etwas ausgefeilterer Ansatz als die reine Codeabdeckung. Es kombiniert Messungen der Codeabdeckung mit Komplexitätsmessungen und zeigt Ihnen dann, welcher komplexe Code derzeit nicht getestet wird.

Meine Antwort auf dieses Rätsel lautet: 100% Zeilenabdeckung des Codes, den Sie testen können, und 0% Zeilenabdeckung des Codes, den Sie nicht testen können.

Meine derzeitige Praxis in Python besteht darin, meine .py-Module in zwei Ordner aufzuteilen: app1 / und app2 / und beim Ausführen von Komponententests die Abdeckung dieser beiden Ordner zu berechnen und visuell zu überprüfen (ich muss dies eines Tages automatisieren), ob app1 100% Abdeckung hat und App2 hat 0% Abdeckung.

Wenn ich feststelle, dass diese Zahlen vom Standard abweichen, untersuche ich das Design des Codes und ändere es so, dass die Abdeckung dem Standard entspricht.

Dies bedeutet, dass ich empfehlen kann, eine 100% ige Zeilenabdeckung des Bibliothekscodes zu erreichen.

Ich überprüfe auch gelegentlich App2 /, um festzustellen, ob ich dort Code testen kann, und wenn ich kann, kann ich ihn in App1 / verschieben.

Jetzt mache ich mir keine allzu großen Sorgen um die Gesamtabdeckung, da diese je nach Größe des Projekts sehr unterschiedlich sein kann, aber im Allgemeinen habe ich 70% bis über 90% gesehen.

Mit Python sollte ich in der Lage sein, einen Rauchtest zu entwickeln, der meine App automatisch ausführt, während die Abdeckung gemessen wird, und hoffentlich ein Aggreagate von 100% erzielt, wenn der Rauchtest mit unpassenden Zahlen kombiniert wird.

Betrachten der Abdeckung aus einer anderen Perspektive: Gut geschriebener Code mit einem klaren Kontrollfluss ist am einfachsten abzudecken, am einfachsten zu lesen und normalerweise am wenigsten fehlerhaft. Wenn Sie Code mit Blick auf Klarheit und Deckbarkeit schreiben und die Komponententests parallel zum Code schreiben, erzielen Sie meiner Meinung nach die besten Ergebnisse.

Meiner Meinung nach lautet die Antwort "Es hängt davon ab, wie viel Zeit Sie haben". Ich versuche 100% zu erreichen, aber ich mache keine Aufregung, wenn ich es nicht mit der Zeit bekomme, die ich habe.

Wenn ich Unit-Tests schreibe, trage ich einen anderen Hut als den Hut, den ich bei der Entwicklung des Produktionscodes trage. Ich denke darüber nach, was der getestete Code zu tun behauptet und in welchen Situationen er möglicherweise beschädigt werden kann.

Ich folge normalerweise den folgenden Kriterien oder Regeln:

1. Dass der Unit Test eine Form der Dokumentation über das erwartete Verhalten meiner Codes sein sollte, d. H. die erwartete Ausgabe bei einer bestimmten Eingabe und die Ausnahmen, die Clients möglicherweise abfangen möchten (Was sollten die Benutzer meines Codes wissen?)

2. Dass der Unit Test mir helfen soll, die Was-wäre-wenn-Bedingungen herauszufinden, an die ich möglicherweise noch nicht gedacht habe. (Wie mache ich meinen Code stabil und robust?)

Wenn diese beiden Regeln keine 100% ige Abdeckung ergeben, dann sei es so. Aber sobald ich Zeit habe, analysiere ich die nicht abgedeckten Blöcke und Linien und stelle fest, ob es noch Testfälle ohne Komponententests gibt oder ob der Code überarbeitet werden muss, um die unnötigen Codes zu beseitigen.

Dies hängt stark von Ihrer Anwendung ab. Beispielsweise bestehen einige Anwendungen hauptsächlich aus GUI-Code, der nicht einheitlich getestet werden kann.

Ich glaube nicht, dass es eine solche S / W-Regel geben kann.
Der Code sollte unter besonderer Berücksichtigung der kritischen Details überprüft werden.
Wenn es jedoch nicht getestet wurde, hat es einen Fehler!

Abhängig von der Kritikalität des Codes ist eine gute Faustregel zwischen 75% und 85%. Der Versandcode sollte auf jeden Fall gründlicher getestet werden als in Hausversorgungsunternehmen usw.

Dies muss davon abhängen, in welcher Phase Ihres Anwendungsentwicklungszyklus Sie sich befinden.

Wenn Sie schon eine Weile in der Entwicklung sind und bereits viel Code implementiert haben und gerade feststellen, dass Sie über die Codeabdeckung nachdenken müssen, müssen Sie Ihre aktuelle Abdeckung überprüfen (falls vorhanden) und diese Basislinie dann verwenden Setzen Sie Meilensteine ​​für jeden Sprint (oder einen durchschnittlichen Anstieg über einen Zeitraum von Sprints), was bedeutet, dass Sie Code-Schulden aufnehmen und gleichzeitig den Endbenutzerwert liefern (zumindest meiner Erfahrung nach ist es dem Endbenutzer egal, ob Sie den Test erhöht haben Abdeckung, wenn sie keine neuen Funktionen sehen).

Abhängig von Ihrer Domain ist es nicht unangemessen, 95% zu fotografieren, aber ich muss sagen, dass Sie im Durchschnitt einen durchschnittlichen Fall von 85% bis 90% betrachten werden.

Ich denke, das beste Symptom für eine korrekte Codeabdeckung ist, dass die Anzahl der konkreten Probleme, die durch Unit-Tests behoben werden können, in angemessener Weise der Größe des von Ihnen erstellten Unit-Test-Codes entspricht.

Ich denke, dass es am wichtigsten sein kann, den Deckungstrend im Laufe der Zeit zu kennen und die Gründe für Änderungen im Trend zu verstehen. Ob Sie die Änderungen im Trend als gut oder schlecht ansehen, hängt von Ihrer Analyse des Grundes ab.

Wir haben bis vor wenigen Tagen> 80% angestrebt. Nachdem wir jedoch viel generierten Code verwendet haben, kümmern wir uns nicht um das Alter in%, sondern veranlassen den Prüfer, einen Anruf über die erforderliche Abdeckung zu tätigen.

Aus dem Testivus-Beitrag denke ich, dass der Antwortkontext der zweite Programmierer sein sollte. Aus praktischer Sicht brauchen wir jedoch Parameter / Ziele, nach denen wir streben müssen. Ich bin der Meinung, dass dies in einem agilen Prozess "getestet" werden kann, indem der Code analysiert wird, über den wir die Architektur und Funktionalität (User Stories) verfügen, und dann eine Nummer erstellt wird. Aufgrund meiner Erfahrung im Bereich Telekommunikation würde ich sagen, dass 60% ein guter Wert für die Überprüfung sind.