Ich bin ein Entwicklungsmanager bei einem Projekt mit einer sehr niedrigen Testabdeckung für Unit-Tests und wir spüren definitiv das Gewicht der "technischen Schuld" im Legacy-Code unseres Systems.
Meine Frage ist, ob jemand Codeabdeckung als Meilenstein oder Entwicklungsschwellenwert verwendet, der verhindert, dass das Projekt zum nächsten Sprint übergeht, bis die Codeabdeckung ein bestimmtes Level erreicht hat. Was ist die "beste Vorgehensweise" für die Verwendung der Code Coverage-Metrik?
Code Coverage ist eine sehr relative Sache. Zunächst einmal, weil die Codeabdeckung allein nichts über die Qualität Ihres Codes oder Ihrer Komponententests aussagt. Zweitens, manchmal ist es leicht, mit nur ein paar Tests eine Abdeckung von 90% zu erreichen, aber manchmal ist es sehr schwer, sogar 50% zu erreichen. Dies gilt insbesondere für ältere Projekte, die häufig nicht für das Testen von Einheiten ausgelegt sind (um beispielsweise externe Abhängigkeiten zu vermeiden).
Wenn Sie es wirklich als Meilenstein verwenden möchten, sollten Sie einige wichtige Klassen Ihres Codes verwenden, z. B. diejenigen, die eine Menge Geschäftslogik haben, und sehen, ob es leicht ist, eine hohe Codeabdeckung in% zu erreichen . Wenn dies der Fall ist, stellen Sie sicher, dass die Codeabdeckung solcher Klassen immer auf dem gleichen Wert bleibt.
Nach meiner Erfahrung braucht es viel Zeit, um eine hohe Codeabdeckung für Legacy-Klassen zu erhalten, und das ist nicht immer die Investition wert.
Ich hoffe, das hilft!
Ich denke, dass die Verwendung von Code-Coverage als Blocker nicht der richtige Weg ist. Der Grund ist, dass es nicht das Hauptziel ist, eine gute Berichterstattung zu haben und dass es sich selbst zum Ziel machen kann. Es ist ziemlich einfach, einfach "Dinge zu tun", um den Messwert zu erhöhen, anstatt ihn tatsächlich zu testen.
Nach meiner Erfahrung ist das Wichtigste, dass Sie tatsächlich etwas tun, während Sie den Code ausführen. Mit anderen Worten, das Wichtigste ist, dass Ihre Tests testen und nicht nur Code ausführen.
Aber verwende Code Coverage als Metrik und feiere angemessen, wenn es zunimmt: -)
Für Legacy-Systeme ist die Einrichtung einer solchen Barriere wahrscheinlich zu schmerzhaft für die gesamte Codebasis , insbesondere wenn die Codebasis nicht-trivial groß ist. Sie können mehr schaden als nützen, zumal die Tilgung dieser technischen Schulden wahrscheinlich zusätzliche Phasen der Instabilität während der unvermeidlichen Refactorings mit sich bringt, die den alten Code auffrischen würden, der wahrscheinlich nicht sehr testfreundlich ist.
Ich würde zielgerichtete Refactorings mit einem Überdeckungsschwellenwert nur für neuen Code empfehlen. Wenn ein Bereich der Codebasis schmerzhaft ist und ein zu hohes Risiko für das Hinzufügen von neuem Code aufweist, dann blockieren Sie einige Zeitspitzen für Redesign und Refactoring. Alle behobenen Fehler sollten nicht bestandene Tests zuerst geschrieben haben, und neue Features sollten eine hohe Abdeckung anstreben, ~ 90% oder höher. (Die letzten 10% der sagenhaften "100%" Abdeckung ist oft sehr kostspielig, da es wahrscheinlich GUI-Ebenen und Integrationsmaterialien beinhaltet. Dies ist eine kontroverse Meinung, aber ich habe festgestellt, dass sie größtenteils gilt. Sei glücklich mit 90% oder höher für neuen Code.)
Der CI-Server für das Projekt, auf dem ich gerade bin, wird den Build nicht bestehen, wenn die Abdeckung unter einen Schwellenwert fällt, aber das ist bei einem Projekt, das mit guter TDD-Praxis begann. Große Legacy-Apps mit vielen technischen Schulden tendieren dazu, mit instabilen Bereichen und politischen Konsequenzen, die kein Trauma mehr brauchen, als sie bereits haben, in die Falle zu gehen. Stellen Sie ein Ziel der allmählichen Verbesserung im Laufe der Zeit und nicht eine einmalige Nachholzeit.
Ich denke, die Code Coverage-Metrik ist etwas grobkörniger, um als solche verwendet zu werden. Wenn Sie es auf bestimmte Bereiche der Codebasis beschränken, könnte es ein bisschen besser sein. Aber bekommst du 80%, wenn du Eigenschaften oder eine Monstermethode testest, die dir die meisten Probleme bereitet?
Ich würde es nicht als Krücke benutzen.
Im Allgemeinen: Wenn Sie Scrum (oder eine andere agile Methode) üben, sollten Sie dem Timeboxing-Prinzip folgen und vermeiden, dass Ihr Sprint verlängert / verzögert wird.
Insbesondere: Die Code Coverage-Metrik allein reicht nicht aus, um den Test- / Bereitschaftsstatus Ihrer Anwendung zu schätzen. Eine komplexere Kombination von Metriken sollte verwendet werden (siehe Bücher zum Softwaretesten).
Ein Code mit hoher Codeabdeckung garantiert keine Codequalität. Von " Die Bedeutung von 100% Testabdeckung "
Was bedeutet 100% Deckung nicht?
Korrektheit. Während 100% Berichterstattung ist eine starke Aussage über das Niveau der Tests, die in ein Stück Code, allein kann es nicht garantieren, dass der Code getestet wird ist völlig fehlerfrei.
Einer der Hauptvorteile beim Erstellen von Komponententests als Teil von Test Driven Development besteht darin, den Code in einen besser testbaren Zustand zu steuern.
Der Versuch, Tests über vorhandenen Code post-hoc hinzuzufügen, kann zu riesigen Testeinrichtungen führen, die Dutzende von Abhängigkeiten einrichten müssen - der Code wurde ursprünglich geschrieben, um als Teil einer Anwendung getestet zu werden, nicht in einem Komponententest. p>
Es wäre ein lohnendes Ziel, das Design der Anwendung noch einmal zu überdenken und den Code so zu überarbeiten, dass er testbar wäre. Dies kann die technische Verschuldung signifikant verringern und gleichzeitig die Testfähigkeit und Wartbarkeit der Codebasis erhöhen. Es könnte auch sehr zeitaufwendig und aus geschäftlicher Sicht nicht wert sein.
Wenn Sie sich mit "Legacy-Code" beschäftigen, wird die Verwendung von Coverage als Blocker Ihnen Schmerzen bereiten. Erfordern Sie, dass neuer Code geschrieben / refaktoriert wird, um abgedeckt zu sein, und Ihr% des veralteten Code im Test sollte natürlich im Laufe der Zeit zunehmen und Sie werden weniger wahrscheinlich das künstliche Gefühl der Sicherheit bekommen, die kommen wird, wenn Sie Abdeckung als ein Blocker verwenden.
Tags und Links unit-testing