2010-08-13 8 views
6

Wir haben begonnen, Part Cover zu verwenden, um die Testcodeabdeckung unserer Anwendung zu verfolgen. IMO ist ein großartiges Werkzeug, um eine Gesamtpunktzahl für Ihre Tests zu erhalten und Testbereiche zu markieren, in denen Sie mit Tests etwas faul gewesen sein könnten, aber heute habe ich einen Test geschrieben und festgestellt, dass es nichts wirklich Nützliches getestet hat meine Berichterstattung!Der Wert der Testcode-Coverage-Tools

Wenn Sie TDD sind, dann schreiben Sie nur Code, um einen Test zu bestehen, und die Tests beschreiben ausführlich alle von der Anwendung benötigten Funktionen. Also ist es in diesem Szenario immer noch sehr wertvoll, eine Coverage-Analyse zu haben?

Für diejenigen von Ihnen, die Coverage-Tools haben, wie religiös halten Sie die Abdeckung bei 100% halten und finden Sie sich schreiben Tests, die nicht wirklich Test alles, aber nur um Ihre Berichterstattung zu halten ? Ist das nicht ein schlechtes Ding?

Antwort

8

Coverage-Tools sollten nur verwendet werden, um Ihnen zu sagen, was nicht getestet wurde. Das Szenario, auf das Sie hingewiesen haben, veranschaulicht, warum Sie sich nicht darauf verlassen können, dass Ihnen gezeigt wird, welcher Code getestet wurde. Tests nur so zu schreiben, dass die Abdeckung 100% ist, ist sinnlos (wie du vermutet hast), und es ist so einfach zu spielen, dass dies keine wirklich nützliche Metrik ist. Ich habe versucht, und bei 100% zu bleiben, aber ich kam zu dem gleichen Schluss, dass Sie getan haben. Ich schrieb Tests, die nichts wirklich prüften, nur damit die Zahlen richtig waren. Verwenden Sie die Tools, um Bereiche zu erkennen, die Sie noch nicht getestet haben, schreiben Sie dann gute Tests oder akzeptieren Sie, dass diese Teile des Codes nicht kritisch sind.

1

Gute Rationalisierung;) Aber wir sind schließlich Menschen, und ich für einen Schlaf viel besser in der Nacht wissen, dass eine ungeprüfte Methode oder Weg hat es nicht in die Produktion geschafft.

2

Wenn Sie pure TDD tun, gibt es weniger Wert für die Code-Abdeckung, weil Sie, wie Sie sagen, nur Code aus Tests schreiben, so dass Sie sowieso bei etwa 100% sein sollten. aber dann ist es wahrscheinlich ziemlich selten (und manchmal nicht möglich), es so rein zu machen.

Wenn Sie nicht reine TDD tun, ist 100% sowieso ein ziemlich unrealistisches Ziel. Normalerweise versuche ich, nach der Methode von Roy Osherove zu gehen und Dinge nur mit Logik zu testen (z. B. nicht gerade Getter/Setter oder Pass-Throughs). Aber dann ist höher immer besser, und es kann verlockend sein, ein paar mehr Tests dort zu setzen, um diese Abdeckung zu erhöhen ..!

7

Ich spiele Devil's Advocate: Wenn die Erhöhung der Abdeckung bedeutet, einen Test zu schreiben, der "nichts nützliches testet", warum war dann dieser Code da? Für mich wäre das ein Argument, um einen Hauptcode zu entfernen.

Oder um einen Test zu entwickeln, der etwas Nützliches tut. Zum Beispiel können Sie bedenken, dass es nicht sinnvoll ist, Setter und Getter zu testen. Ich auch nicht. Diese Methoden sollten jedoch getestet werden, während etwas anderes getestet wird. Ansonsten, warum sind sie wieder da?

Aber Sie heben einen guten Punkt, dass Coverage-Tools kein Selbstzweck sein sollten. Zumal sie Ihnen nicht sagen können, welchen Code Sie schreiben müssen.

Ich habe hier mehr ins Detail gegangen: http://www.kdgregory.com/index.php?page=junit.coverage

+1

Gute Blog-Post. Die beschämende Wahrheit ist, dass ich in einigen POCO-Klassen sehr gut trainierte. Was Sie enthüllten, wie Sie sagten, war, dass sie sich durch die bedeutungsvollen Tests nicht ausübten. Der Grund - zu schwer zu testen. Dieser alte Code war in den Gubbins von allem und zu eng gekoppelt. Die wirkliche Lösung ist eine Refactoring-Sitzung. –