Code-Coverage nur bei neuem Code messen

Question

Wir suchen nach einer kreativen Methode, um die Codeabdeckung für neuen Code getrennt vom vorhandenen Code zu messen. Wir haben ein großes Legacy-Projekt und möchten mit einer neuen Funktionalität 90 +% abdecken. Wir möchten auf einfache Weise einen Bericht anzeigen, der älteren Code herausfiltert, um sicherzustellen, dass die neue Funktionalität unser Ziel erreicht. Offensichtlich suchen wir immer noch nach einer umfassenden Berichterstattung über das Projekt, benötigen aber einen nicht manuellen Weg, um uns Feedback zu den neuen Code-Aktivitäten zu geben. Wir können dies für die statische Analyse verwenden, da wir die Daten in den Quelldateien betrachten können. Da Cobertura die Klassendateien analysiert, haben sie neue Daten und diese Technik funktioniert nicht.

Irgendwelche Ideen?

Stack:

Java 1.5 JUnit Cobertura Hudson

Answer 1

Werfen Sie einen Blick auf emma.sourceforge und damit verbundene Eclipse-Plugin here (wenn Verwendung von Eclipse)

Ich denke, das Werkzeug beantworten Sie müssen genau auswählen, was Sie für die Abdeckung testen möchten.

Answer 2

Wir hatten eine ähnliche Situation .. wollte neuen Code getestet, konnte aber nicht alle alten Code auf einmal testen. Was wir getan haben, ist nicht genau das, was Sie gefragt haben, aber vielleicht geben Sie Ihnen eine Idee.

Wir haben eine Datei namens linecoverage.standard, und eine Datei namens branchcoverage.standard, die auf dem Build-Server (und lokalen Kopien) leben. Sie haben eine Nummer mit den aktuellen Begrenzungen für die Zeilen- und Zweigabdeckung. Wenn der eingecheckte Code unter dem Standard liegt, schlägt der Build fehl. Wenn es dem Standard entspricht, übergibt es den Build. Wenn es ÜBER dem Standard ist, wird ein neuer Standard gleich der aktuellen Abdeckung geschrieben.

Dies bedeutet, dass unsere Codeabdeckung nie schlechter wird und langsam steigen sollte. Wenn der neue Code 90% beträgt, wird die Abdeckung weiter ansteigen. Sie können auch ein Ziel setzen, indem Sie den Standard jede Woche um 1 erhöhen, bis Ihr Endziel erreicht ist (90%). Es ist keine schlechte Idee, dem alten Code ein paar Tests pro Woche hinzuzufügen, wenn er über genug Zeit verteilt ist.

Unsere aktuelle Abdeckung ist bis zu 75% ish ... ziemlich gut von 0% Rate unter einem Jahr.

Answer 3

Ich tat dies für ein großes C++ Projekt mit svn blame kombiniert mit der Ausgabe von gcov. Wenn Sie diese beiden Ergebnisse zusammenführen, haben Sie für jede Zeile Revisionsinformationen und Abdeckungsinformationen. Ich lud wirklich das alles in eine Datenbank, um Fragen zu tun (z. B. zeigen Sie mir alle aufgedeckten Linien, die von Joe seit r1234 geschrieben werden). Wenn Sie nur eine aggregierte Nummer möchten, können Sie einfach vermeiden, "alte" unbedeckte Zeilen in Ihrer Gesamtsumme zu zählen.

Answer 4

IMO die beste Option ist es, die Codebasis in "neue" und "Legacy" Abschnitte zu teilen. Führen Sie dann entweder nur eine Testüberdeckungsanalyse für den Abschnitt "new" aus, oder ignorieren Sie die Ergebnisse für den Abschnitt "old".

Die zwei besten Möglichkeiten, dies zu erreichen, sind a) teilen Sie die Codebasis in zwei Quellbäume (zwei Projekte mit einer Abhängigkeit zwischen), oder b) zwei separate Pakethierarchien in einem einzigen Projekt.

Zwei separate Projekte sind wahrscheinlich vorzuziehen, aber es ist möglicherweise nicht möglich, wenn zwischen der alten Codebase und der neuen Codebasis eine zyklische Abhängigkeit besteht (alter Code hängt von neuem Code ab und neuer Code von altem Code). Wenn Sie es verwalten können, wird auch eine unidirektionale Abhängigkeit zwischen altem und neuem Code die kombinierte Codebasis leichter verständlich machen.

Sobald Sie dies erledigt haben, passen Sie cobertura entweder so an, dass es nur die gewünschten Bits analysiert, oder konzentrieren Sie sich zumindest auf den "neuen" Teil der Codebasis. Ein weiterer Tipp ist, dass es in diesem Schema am besten ist, Code-Bits aus dem "Legacy" -Bereich in den "New" -Bereich zu verschieben, wenn Sie Tests umgestalten/hinzufügen (wenn Code sich häufig in die andere Richtung bewegt, ist das nicht der Fall) gut :-).

Answer 5

Wir haben es wie folgt getan mit sonar.exclusions property: Wir verwenden Sonar, um die Code-Coverage-Berichte anzuzeigen (gemeldet von Cobertura).

a) Identifizieren Sie die Klassen, für die Sie keinen Abdeckungsbericht wünschen (Legacy-Klassen) Verwenden Sie Ihren SCM-cmd-Linienclient. zB: p4 files // depot/... @ 2000/01/01, @ 2013/07/13 git log --until = "vor 5 Tagen"

Diese Liste in eine Datei umleiten. Sie müssen ein Parsing basierend auf dem SCM-Tool durchführen, das Sie verwenden, und Ihre Zieldatei sollte einen Dateinamen pro Zeile enthalten.

eg. the destination file is excludeFile.list should look like below: 
abc.java 
xyz.java 
... 

b) Wenn Sie jetzt mit Sonar (von Jenkins Job) integrieren, verwenden Sie die folgende Eigenschaft.

-Dsonar.exclusions=<filename> 

Und Ihr endgültige Abdeckung Bericht in Sonar enthält nur Ihre neue Klassen (zugegeben nach 13.07 in dem obigen Beispiel).