Quando ha senso includere il codice di test nella copertura?

6

Molti strumenti di copertura valutano un intero progetto, incluso il codice di test unitario stesso. In VS 2013, l'opzione Analizza copertura codice / Tutti i test include il codice di test nel suo report. OpenCover lo fa anche io credo. In Eclipse, un progetto Maven con la tipica configurazione src / main / java e src / test / java, EclEmma riporterà la copertura per il codice principale e di test

Questo mi sembra un valore minimo, tranne che per assicurarmi che tutti i test vengano effettivamente eseguiti. Con il codice di prova incluso, la percentuale di copertura è spesso artificialmente alta poiché spesso lo strumento segnalerà una copertura vicina al 100% per il codice di prova, che può inclinare l'intero progetto al di sopra di un livello di riferimento (80%) che altrimenti non avrebbe ottenuto.

Esistono motivi legittimi per includere il codice di prova nella copertura? O dovrei continuare a filtrarlo quando automatizziamo i nostri rapporti sulla copertura?

    
posta Dan1701 02.02.2016 - 09:13
fonte

1 risposta

6

Non direi esattamente le ragioni, ma forniscono un buon controllo dei sensi. Tutti i test sono gli stessi (non attribuiti), ci si aspetterebbe che questo sia al 100% per una corsa completa. Qualunque cosa in meno di questo suggerisce che hai un codice morto che potrebbe essere rimosso.

Per i build CI , è abbastanza comune ignorare i test di integrazione, quindi è utile (per me come build manager ) per vedere questo come so che la soluzione sotto test ha un elemento di integrazione o simile.

Può anche essere una pistola fumante per gli sviluppatori che cercano di nascondere i loro test non funzionanti con l'attributo Ignore . Abbiamo avuto un cowboy che ha rotto i test e poi ha semplicemente aggiunto altri per coprirlo. Il conteggio dei test è rimasto lo stesso, ma la copertura è diminuita nel tempo. Inutile dire che presto ha mostrato la porta!

    
risposta data 02.02.2016 - 12:02
fonte

Leggi altre domande sui tag