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

In genere escludo il codice generato automaticamente, come i client WCF generati da Visual Studio. Di solito ci sono molte linee di codice e non le testeremo mai. Ciò rende molto demoralizzante aumentare i test su un'ampia porzione di codice altrove e aumentare la copertura del codice solo dello 0,1%.

Escluderò anche le interazioni a livello di dati, purché il team possa dire con certezza che questo strato è il più sottile possibile. Mentre si può sostenere che, se il livello è sottile, non avrà un effetto enorme, ma lascia un sacco di componenti nel report di copertura con lo 0% contro di essi, quindi non necessariamente notiamo quelli di cui abbiamo bisogno davvero preoccuparsi. Il livello dell'interfaccia utente potrebbe essere discusso in modo simile, a seconda del framework utilizzato.

Ma, come contro-punto, escluderò anche i test unitari. Dovrebbero sempre avere una copertura del ~ 100% e ammontano a una grande percentuale del codice, distorcendo le cifre pericolosamente verso l'alto.

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

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

Perché l'ultimo punto? Penso che sia una buona pratica concentrarsi sulle cose a cui tengo, mentre sopprime le distrazioni. Se non intendi testare il livello dell'interfaccia utente, perché prenderlo in considerazione, attirerà solo l'attenzione sulla parte importante del tuo software, la logica del business.

MA:

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

Infine: non prendere numeri troppo seri. La copertura del 30% può dimostrare un solido software, quando è la parte essenziale di esso.

Tendo ad essere d'accordo con te e includo tutto il codice pertinente nelle metriche di copertura del codice (e in generale il Sonar). Anche se non si prevede di testare alcune parti del codice (per il prevedibile futuro), le metriche dovrebbero riflettere lo stato attuale. Questo ti costringe ad avere una ragione convincente per non scrivere test per una parte significativa del codice base. Alla fine (una volta che sono già coperte altre parti più importanti del codice) puoi riconsiderare o scegliere un modo diverso per eliminare questa dissonanza - ad es. rifattorizzando il codice in questione per renderlo testabile, o per migrare tutta la logica da esso in una diversa parte testabile della base di codice, o anche per eliminare del tutto l'intero livello (se un livello non vale la pena di test, ha una buona ragione sufficiente per esistere?)

Nei miei progetti attuali, includiamo anche tutto il codice nelle metriche, con un'eccezione: codice generato, che produce un mucchio di avvisi di analisi statici. Poiché questo codice in genere consiste in classi POD gigantesche senza alcuna logica, non c'è nulla da testare comunque.

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

Con le mie conoscenze limitate ho questo da dire:

1. Non lasciare che i numeri con qualsiasi tipo di strumenti di test ostacolino i tuoi test.
2. Se le classi sono complesse e non sono testabili, è sempre una buona idea ridirigerli in classi più compatte e testabili. Richiederà molto impegno e dedizione, ma a lungo termine pagherà.
3. Il test dei componenti dell'interfaccia utente può essere difficile, ma è comunque possibile testare la funzione che viene 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 un buon test. Concentrati sul rendere le librerie principali più robuste e testabili piuttosto che puntare a una percentuale più elevata.

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

Suggerisco di segnalare un set di metriche per ogni livello del codice. Queste metriche devono includere informazioni sulle dimensioni (ad esempio, LoC, numero di librerie, numero di classi o metodi, ecc.), Informazioni sui test (ad es. Copertura) e informazioni sui bug (ad es., Trovare e correggere i tassi).

I tuoi livelli esclusi avranno una copertura dello 0% e le tue aree testate avranno il 60% di copertura che hai menzionato. Le informazioni sulla dimensione consentiranno alle persone di capire quanto non è testato o testato. Le informazioni sui bug ti informeranno se forse dovresti creare test per i livelli esclusi e se i test esistenti stanno funzionando.

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