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 bevorzuge BDD, das eine Kombination aus automatisierten Akzeptanztests, möglicherweise anderen Integrationstests und Unit-Tests verwendet. Die Frage, die sich mir stellt, ist, wie hoch die angestrebte Abdeckung der automatisierten Testsuite als Ganzes sein sollte.

Abgesehen davon hängt die Antwort von Ihrer Methodik, Sprache und Ihren Test- und Abdeckungswerkzeugen ab. Bei TDD in Ruby oder Python ist es nicht schwer, eine 100%ige Abdeckung zu erreichen, und es lohnt sich, dies zu tun. Es ist viel einfacher, eine 100-prozentige Abdeckung zu erreichen als eine 90-prozentige. Das heißt, es ist viel einfacher zu füllen Abdeckung Lücken, wie sie erscheinen (und wenn TDD gut Abdeckung Lücken sind selten und in der Regel Ihre Zeit wert), als es ist, eine Liste der Abdeckung Lücken, die Sie nicht bekommen haben, um und verpassen Abdeckung Regressionen aufgrund Ihrer ständigen Hintergrund der unbedeckten Code zu verwalten.

Die Antwort hängt auch von der Vorgeschichte Ihres Projekts ab. Ich habe nur bei Projekten, die von Anfang an auf diese Weise verwaltet wurden, festgestellt, dass die oben genannten Maßnahmen sinnvoll sind. Ich habe die Abdeckung von großen Legacy-Projekten erheblich verbessert, und es hat sich gelohnt, aber ich habe es nie als praktisch empfunden, zurückzugehen und jede Abdeckungslücke zu schließen, weil alter, ungetesteter Code nicht gut genug verstanden wird, um dies korrekt und schnell zu tun.

Answer 2

Wenn ich der Meinung bin, dass mein Code nicht ausreichend getestet wurde und ich nicht sicher bin, was ich als Nächstes testen soll, verwende ich die Abdeckung, um zu entscheiden, was ich als Nächstes testen soll.

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

Dies gilt für Codes, die nicht, zu 50 % oder zu 97 % abgedeckt sind.

Answer 3

Ich verwende cobertura, und unabhängig vom Prozentsatz würde ich empfehlen, die Werte in der Aufgabe cobertura-check aktuell zu halten. Erhöhen Sie zumindest totallinerate und totalbranchrate auf einen Wert, der knapp unter der aktuellen Abdeckung liegt, aber niemals diese Werte zu senken. Binden Sie auch die Eigenschaft "Ant build failure" in diese Aufgabe ein. Wenn der Build wegen mangelnder Abdeckung fehlschlägt, wissen Sie, dass jemand Code hinzugefügt hat, ihn aber nicht getestet hat. Beispiel:

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

Answer 4

Code Coverage ist großartig, aber nur so lange, wie der Nutzen, den man daraus zieht, die Kosten/Aufwendungen überwiegt, die mit der Umsetzung verbunden sind.

Wir haben eine Zeit lang nach einem Standard von 80 % gearbeitet, aber wir haben gerade beschlossen, dies aufzugeben und uns stattdessen mehr auf unsere Tests zu konzentrieren. Wir konzentrieren uns auf die komplexe Geschäftslogik usw,

Diese Entscheidung wurde aufgrund des zunehmenden Zeitaufwands getroffen, den wir für die Codeabdeckung und die Pflege bestehender Unit-Tests aufwenden. Wir hatten das Gefühl, dass wir an einen Punkt gelangt waren, an dem der Nutzen, den wir aus unserer Codeabdeckung zogen, geringer erschien als der Aufwand, den wir dafür betreiben mussten.

Answer 5

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

Ich würde wahrscheinlich eine Reihe von höheren Werten für die Versandkriterien wählen - je nach der Kritikalität der zu prüfenden Teilsysteme/Komponenten.