Integrazione continua: assicurarsi che i nuovi commit siano coperti con i test

Sto lavorando su un progetto che ha un sacco di codice legacy che non è coperto da test.Integrazione continua: assicurarsi che i nuovi commit siano coperti con i test

Esiste un modo per configurare il server di integrazione per verificare che tutti i nuovi commit abbiano una quantità minima di test (ad esempio, la copertura è> 70%)?

In sostanza, vedo due opzioni:

In qualche modo configurare il server CI di fallire la compilazione quando cambia impegnati non sono coperti con test di unità. Ciò garantirà che ogni parte del nuovo codice abbia dei test e che i test per il codice legacy aumenteranno ad ogni cambio.
Impostare una soglia di copertura per l'intero progetto e fallire la costruzione se la percentuale di copertura diminuisce dopo un commit. Il problema con questo è che se cancello una classe contenente 100 istruzioni e aggiungo una nuova classe con 50 istruzioni la percentuale di copertura salirà senza che io scriva alcun test.

Mi piace l'opzione 1 altro perché impone che le modifiche nel codice legacy vengano sottoposte a test dell'unità. Ciò dovrebbe aumentare la copertura complessiva del test.

In questo momento stiamo utilizzando Jenkins come nostro server CI e JaCoCo per la copertura di test. Maven è usato per la costruzione del progetto e SVN è il nostro principale controllo del codice sorgente.

fonte

2013-04-03 Denis Rosca

Tenere presente che una copertura del 100% non è necessariamente possibile o addirittura desiderata. Anche i numeri di copertura possono essere manipolati; scrivere un test unitario per una classe di test può gonfiare artificialmente la copertura del test. –

@ MikeRylander Lo so, non sogna nemmeno una copertura al 100% su questo progetto. Ma continuo a pensare che forzare nuove modifiche per avere almeno una certa copertura sia buona. –

Attualmente sto lavorando a una soluzione a questo problema che si rivolge in gran parte al commento di @MikeRylanders. http://pitest.org è ora integrato con il controllo della versione. La prossima versione consentirà l'analisi dei file in base allo stato scm. La seguente versione consentirà l'analisi per intervallo di date o commit, che consentirebbe a un server di generazione di verificare che il codice modificato abbia soddisfatto un determinato punteggio di mutazione. – henry

So che è possibile configurare Jenkins per verificare che vi sia almeno un file di prova come parte del commit. Ciò non assicurerebbe una buona copertura del test, ma almeno sapresti che ci sono stati alcuni tipi di cambiamenti relativi ai test.

fonte

2013-04-03 18:47:36

Non mi piace questa idea. Se si sta commettendo qualcosa per eseguire un passaggio di prova in precedenza non riuscito, non è necessario anche impegnare un file di test. – JohnnyO

@JohnnyO In teoria una build fallita ** non dovrebbe ** essere impegnata in primo luogo. A meno che i tuoi test unitari siano instabili o legati a dipendenze esterne, il che è un insieme diverso di problemi, non dovresti mai fare un commit per correggere i test unitari guasti. –

In teoria, certo. In pratica, non così tanto. Immagina di avere un brutto commit (diciamo che ti sei dimenticato di includere un file). Quindi, il test è passato a livello locale, ma non è riuscito a Jenkins. In che modo commetteresti il file mancante in quel caso? – JohnnyO

Per l'opzione 2, è possibile utilizzare Jenkins JaCoCo plugin per tenere traccia della copertura del codice per ogni build e impostare il risultato della build su superato o non riuscito a seconda delle metriche di copertura.

Mi piace anche l'opzione 1, ma non conosco un modo integrato per Jenkins per farlo. Dovrebbe essere abbastanza facile (almeno a livello di classe) di post-processo i dati di copertura e combinarlo con le informazioni di revisione SVN, qualcosa di simile:

analizzare i file di output JaCoCo e trovare le classi che hanno 0% copertura
Ottieni i file modificati per questa build dai dettagli della revisione SVN (Jenkins rende disponibili i numeri di revisione nelle variabili di ambiente, SVN_REVISION se ce n'è uno solo per questa build o SVN_REVISION_1, SVN_REVISION_2, ... per più
Stampare un messaggio di errore se una delle classi modificate ha una copertura dello 0%
Utilizzare Jenkins Text Finder plugin fallire la compilazione se viene stampato il messaggio di errore.

Questa non è una soluzione completa, diventa più complicata per nuovi metodi o linee che non sono coperti dai test. Mi dà un'idea per un nuovo plugin Jenkins ;-)

fonte

2013-04-03 18:48:09

ma come posso configurare questo plugin per fallire se le modifiche apportate non sono coperte con i test? Se aggiungo una piccola modifica in un file legacy, questo potrebbe non cambiare la metrica di copertura generale e quindi non fallirà la costruzione? –

Giusto, è per questo che ho incluso i miei commenti sulla tua prima opzione. –

Aspetterò con ansia il tuo plugin. –

Alcuni strumenti di copertura (come la cobertura) supportano pacchetti esclusi. In questo modo, puoi escludere tutto il vecchio codice (supponendo che possa essere abbinato al modello) e fare in modo che la cobertura verifichi solo il nuovo codice (che copre i nuovi commit).

Spero che questo aiuti.

fonte

2013-04-03 18:50:46

grazie per l'input, ma il mio obiettivo era garantire che il nuovo codice fosse testato e anche forzare le modifiche al codice legacy da testare. –

ho costruito uno strumento che fa esattamente questo

https://github.com/exussum12/coverageChecker

Si passa nel diff del ramo e l'uscita di test coperchio dalle prove. Lo strumento individua quali linee nel diff sono anche nel file clover. e non riesce la build se meno di una certa percentuale

utilizzare

bin/diffFilter --phpunit diff.txt clover.xml 70

a fallire costruisce quando meno del 70% del diff è coperto da una prova

posso aggiungere altri formati, se necessario

Modifica

ho aggiunto jacoco

Bin/diffFilter --jacoco diff.txt jacoco.xml

fonte

2017-08-17 16:46:27 exussum

Integrazione continua: assicurarsi che i nuovi commit siano coperti con i test

risposta

Problemi correlati