Dovremmo escludere il codice per l'analisi della copertura del codice?

Sto lavorando su diverse applicazioni, principalmente quelle legacy. Attualmente, la copertura del loro codice è piuttosto bassa: generalmente tra il 10 e il 50%.

Da diverse settimane, abbiamo discussioni ricorrenti con i team di Bangalore (la parte principale dello sviluppo viene effettuata in mare aperto in India) in merito alle esclusioni di pacchetti o classi per Cobertura (il nostro strumento di copertura del codice, anche se stiamo attualmente migrando verso JaCoCo).

Il loro punto di vista è il seguente: poiché non scriveranno alcun test unitario su alcuni livelli dell'applicazione (1) , questi livelli dovrebbero essere semplicemente esclusi dalla misura di copertura del codice. In altre parole, vogliono limitare la misura di copertura del codice al codice testato o che dovrebbe essere testato .

Inoltre, quando lavorano su unit test per una classe complessa, i vantaggi - puramente in termini di copertura del codice - saranno inosservati a causa di un'applicazione di grandi dimensioni. Ridurre l'ambito della copertura del codice renderà più visibile questo tipo di sforzo ...

L'interesse di questo approccio è che avremo una misura di copertura del codice che indica lo stato corrente della parte dell'applicazione che consideriamo testabile .

Tuttavia, il mio punto di vista è che stiamo in qualche modo falsificando le cifre. Questa soluzione è un modo semplice per raggiungere un livello più elevato di copertura del codice senza alcuno sforzo. Un altro punto che mi preoccupa è il seguente: se mostriamo un aumento della copertura da una settimana all'altra, come possiamo sapere se questa buona notizia è dovuta al buon lavoro degli sviluppatori o semplicemente a nuove esclusioni?

Inoltre, non saremo in grado di sapere esattamente cosa viene considerato nella misura di copertura del codice. Ad esempio, se ho un'applicazione di 10.000 righe di codice con il 40% di copertura del codice, posso dedurre che viene testato il 40% della mia base di codice (2) . Ma cosa succede se impostiamo esclusioni? Se la copertura del codice è ora del 60%, cosa posso dedurre esattamente? Che il 60% del mio "importante" codice di base è stato testato? Come posso

Per quanto mi riguarda, preferisco mantenere il valore "reale" della copertura del codice, anche se non possiamo essere felici. Inoltre, grazie a Sonar, possiamo facilmente navigare nella nostra base di codici e conoscere, per qualsiasi modulo / pacchetto / classe, la propria copertura di codice. Ma ovviamente, la copertura del codice globale sarà ancora bassa.

Qual è la tua opinione su questo argomento? Come fai sui tuoi progetti?

Grazie.

(1) Questi livelli sono generalmente correlati all'interfaccia utente / bean Java, ecc.

(2) So che non è vero. In realtà, significa solo che il 40% della mia base di codice

In genere escludo il codice generato automaticamente, ad esempio i client WCF generati da Visual Studio. Di solito ci sono molte righe di codice lì e non le testeremo mai. Ciò rende molto demoralizzante aumentare i test su una grande porzione di codice altrove e aumentare la copertura del codice solo dello 0,1%.

Escluderò anche le interazioni del livello dati, purché il team possa affermare con certezza che questo livello è il più sottile possibile. Sebbene tu possa sostenere che, se il layer è sottile, non avrà un effetto enorme, lascia molti componenti nel report di copertura con lo 0% rispetto a loro, quindi non notiamo necessariamente quelli di cui abbiamo bisogno di cui preoccuparsi davvero. Il livello dell'interfaccia utente potrebbe essere argomentato in modo simile, a seconda del framework utilizzato.

Ma, come contrappunto, escluderò anche i test unitari stessi. Dovrebbero avere sempre una copertura del ~ 100% e ammontano a una grande percentuale della base di codice, inclinando pericolosamente le cifre verso l'alto.

Buona domanda. In generale, tendo ad escludere il codice dalla copertura del codice per alcuni motivi, ad esempio:

• generato
• legacy (non più aggiornato)
• ecco che arriva: alcuni livelli, non ho intenzione di testare

Perché l'ultimo punto? Penso che sia una buona pratica concentrarsi sulle cose a cui tengo, mentre sopprimere le distrazioni. Se non hai intenzione di testare l'UI-Layer, perché prenderlo in considerazione - attirerebbe solo l'attenzione dalla parte importante del tuo software - la logica aziendale.

MA:

1. Dovresti avere una buona ragione, perché escludere un certo livello dai test unitari (potrebbero esserci delle domande: dal tuo capo, dai tuoi compagni di squadra, dalla stampa ;-)
2. Se vuoi che testino questi livelli, dovresti includerli nelle statistiche per mostrare a tutto il team, ogni giorno che è importante e deve essere fatto.

Infine: non prendere i numeri troppo sul serio. Una copertura del 30% può dimostrare che un software è solido, quando ne costituisce la parte essenziale.

Tendo ad essere d'accordo con te e includere tutto il codice rilevante nelle metriche di copertura del codice (e Sonar in generale). Anche se non prevedi di testare alcune parti del codice (per il futuro prevedibile), le metriche dovrebbero riflettere lo stato effettivo. Questo ti costringe ad avere un motivo convincente per non scrivere test per una parte significativa della base di codice. Alla fine (un'altra volta, parti più importanti del codice sono già coperte) è possibile riconsiderare o scegliere un modo diverso per eliminare questa dissonanza, ad esempio riformattando il codice in questione per renderlo testabile o migrare tutta la logica da esso in un parte diversa e testabile della base di codice, o addirittura per eliminare del tutto l'intero livello (se un livello non vale la pena testarlo, ha una ragione sufficiente per esistere?)

Nei miei progetti attuali, includiamo anche tutto il codice nelle metriche, con una sola eccezione: il codice generato, che produce un sacco di avvisi di analisi statica. Poiché questo codice è in genere costituito da enormi classi POD senza alcuna logica, non c'è comunque nulla da testare lì.

Ora non conosco molto bene gli strumenti di copertura del codice che stai utilizzando, né ho familiarità con i bean Java, ma da quello che dici sono correlati all'interfaccia utente.

Con la mia conoscenza limitata ho questo da dire:

1. Non permettere ai numeri di alcun tipo di strumento di test di ostacolare i tuoi test.
2. Se le classi sono complesse e non sono verificabili in unità, è sempre una buona idea ricodificarle in classi più compatte e verificabili. Richiederà molto impegno e dedizione, ma pagherà nel lungo periodo.
3. Il test dei componenti dell'interfaccia utente può essere difficile, ma è comunque possibile testare la funzione eseguita da tali componenti.
4. Se stai facendo un progetto basato sul web, puoi usare QUnit per testare tutto il codice lato client.

Tutto sommato, tieni presente che la copertura del codice è solo un numero e che la copertura del codice elevato non indica buoni test. Concentrati sul rendere le librerie di base più robuste e testabili piuttosto che puntare a una percentuale più elevata.

Alcune esclusioni hanno senso (codice della piastra della caldaia che non ha alcun impatto reale o potenziale impatto sul corretto funzionamento del progetto). Anche raccogliere la copertura del codice come metrica è inutile perché non ti dice comunque nulla di utile. La copertura del codice al 100% non è un obiettivo reale e anche i numeri a bassa copertura potrebbero non essere negativi a seconda del progetto, potrebbe essere possibile che una copertura del codice del 20-30% copra tutto ciò che vale la pena testare. la copertura del codice ti dice solo che l'X% del tuo codice che potenzialmente vale la pena coprire è in realtà con un tipo di test di qualità sconosciuta.

Suggerisco di segnalare una serie di metriche per ogni livello del codice. Queste metriche dovrebbero includere informazioni sulle dimensioni (ad es. LoC, numero di librerie, numero di classi o metodi, ecc.), Informazioni sui test (ad es. Copertura) e informazioni sui bug (ad es. Ricerca e correzione di tariffe).

I livelli esclusi avranno una copertura dello 0% e le aree testate avranno la copertura del 60% menzionata. Le informazioni sulle dimensioni consentiranno alle persone di capire quanto non è stato testato o testato. Le informazioni sui bug ti informeranno se forse dovresti creare test per i layer esclusi e se i test esistenti funzionano.

È facile per le organizzazioni di software concentrarsi troppo sulla purezza delle metriche. Non facciamo metriche, facciamo un buon software. Una metrica che ti aiuta a fornire software di alta qualità in modo tempestivo è la metrica più onesta e pura che ci sia.