Misurare la copertura del codice solo sul nuovo codice

Question

Stiamo cercando un modo creativo per misurare la copertura del codice sul nuovo codice separato dal codice esistente. Abbiamo un grande progetto legacy e vogliamo iniziare a ottenere una copertura del 90% su qualsiasi nuova funzionalità. Vorremmo un modo per visualizzare facilmente un rapporto che filtra tutti i vecchi codici per assicurarci che la nuova funzionalità soddisfi il nostro obiettivo. Ovviamente sembra ancora una copertura complessiva crescente del progetto, ma è necessario un modo non manuale per darci un feedback sulla nuova attività del codice. Abbiamo questo lavoro per l'analisi statica dal momento che possiamo guardare le date sui file di origine. Poiché Cobertura sta analizzando i file di classe, hanno nuove date e questa tecnica non funziona.

Qualsiasi idea?

Stack:

Java 1.5 JUnit Cobertura Hudson

Answer 1

avere uno sguardo su emma.sourceforge e associato Plug-in Eclipse here (se si utilizza Eclipse)

penso che questo strumento può rispondere a il tuo bisogno selezionando esattamente cosa testare per la copertura.

Answer 2

Abbiamo avuto una situazione simile. Volevamo un nuovo codice testato ma non è stato possibile testare tutto il vecchio codice in una sola volta. Quello che abbiamo fatto non è esattamente quello che hai chiesto, ma potrebbe darti un'idea.

Abbiamo un file chiamato linecoverage.standard e un file chiamato branchcoverage.standard che risiede sul build server (e copie locali). Hanno un numero interno con i limiti di copertura della linea e della diramazione correnti. Se il codice registrato è inferiore allo standard, fallisce la compilazione. Se è allo standard passa la build. Se è SOPRA lo standard, un nuovo standard è scritto uguale alla copertura corrente.

Ciò significa che la copertura del nostro codice non peggiorerà mai e dovrebbe aumentare lentamente. Se il nuovo codice è del 90%, la copertura continuerà a salire. Puoi anche impostare un obiettivo come aumentare lo standard di 1 ogni settimana fino a raggiungere il tuo obiettivo finale (90%). Dover aggiungere qualche test alla settimana al vecchio codice non è una cattiva idea, se è distribuito su un tempo sufficiente.

La nostra copertura attuale è fino al 75% ish ... abbastanza buono proveniente da una percentuale dello 0% rispetto a un anno fa.

Answer 3

Ho fatto questo per un grande progetto C++ usando svn blame combinato con l'output di gcov. Se si comprimono insieme questi due risultati, sono disponibili informazioni sulla revisione e informazioni sulla copertura per ciascuna linea. In realtà ho caricato tutto questo in un database per eseguire query (ad esempio mostrami tutte le righe scoperte scritte da joe da r1234). Se si desidera solo un numero aggregato, è possibile evitare di contare le "vecchie" linee scoperte nel totale.

Answer 4

IMO l'opzione migliore è dividere il codebase in sezioni "nuove" e "legacy". Quindi eseguire l'analisi della copertura del test solo nella sezione "nuova" oppure ignorare i risultati per la sezione "precedente".

I due modi migliori per eseguire ciò sono: a) dividere il codice in due alberi di origine (due progetti con una dipendenza tra) oppure b) mantenere due gerarchie di pacchetti distinte in un singolo progetto.

Probabilmente sono preferibili due progetti separati, ma potrebbe non essere possibile se esiste una dipendenza ciclica tra la base di codice legacy e la nuova base di codice (il vecchio codice dipende dal nuovo codice e il nuovo codice dipende dal vecchio codice). Se riesci a gestirlo, una dipendenza unidirezionale tra il vecchio e il nuovo codice renderà anche più comprensibile la base di codici combinata.

Una volta terminato, regola Cobertura in modo che analizzi solo i bit desiderati, o almeno concentrati solo sulla "nuova" parte del codice base. Un suggerimento addizionale è che in questo schema, è meglio spostare bit di codice dalla sezione "legacy" alla sezione "new" mentre si refactoring/aggiungere test a loro (se il codice si sposta di frequente nella direzione opposta, non è così bene :-).

Answer 5

L'abbiamo fatto come segue utilizzando la proprietà sonar.exclusions: Utilizziamo Sonar per visualizzare i report di copertura del codice (riportati da Cobertura).

a) Identificare le classi su cui non si desidera eseguire il report di copertura (Classi precedenti) Utilizzare il client della linea cmd SCM. ad esempio: i file p4 // depot/... @ 2000/01/01, @ 2013/13/07 git log --until = "5 giorni fa"

diretto questa lista in un file. È necessario eseguire alcune analisi in base allo strumento SCM che si utilizza e il file di destinazione deve contenere un nome file per riga.

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

b) Ora ... quando si integra con Sonar (da Jenkins Job), utilizzare la proprietà sottostante.

-Dsonar.exclusions=<filename> 

E il tuo rapporto di copertura finale nel Sonar contiene solo le nuove classi (aggiunto dopo 07/13 nell'esempio di cui sopra).