it-swarm.it

Quanta copertura del codice è "sufficiente"?

Stiamo iniziando un Push per la copertura del codice qui nel mio lavoro, e mi ha fatto pensare .... Quanta copertura del codice è sufficiente?

Quando arrivi al punto di rendimenti decrescenti sulla copertura del codice? Qual è il punto debole tra una buona copertura e non abbastanza? Varia in base al tipo di progetto che stai realizzando (ad es. WPF, WCF, Mobile, ASP.NET) (Queste sono le classi C # che stiamo scrivendo).

38
Vaccano

Puntiamo a almeno 70%. Su cose che sono più facilmente verificabili (strutture di dati funzionali, ad esempio), puntiamo al 90% e la maggior parte degli individui punta il più vicino possibile al 100%. Per quanto riguarda le cose relative al WPF e altri framework che sono molto difficili da testare, otteniamo una copertura molto più bassa (appena il 70%).

19
Noah Richards

Sono dell'opinione che la sola copertura del codice sia una metrica scadente. È facile produrre tonnellate di test inutili che copertina il codice, ma non controllano adeguatamente l'output o non testano casi Edge, ad esempio. Il codice di copertura significa solo che non genera un'eccezione, non che sia giusto. Hai bisogno di test di qualità: la quantità non è così importante.

55
Fishtoaster

"Basta" è quando puoi apportare modifiche al tuo codice con sicurezza che non stai rompendo nulla. In alcuni progetti, questo potrebbe essere del 10%, in altri potrebbe essere del 95%.

Non arriva quasi mai al 100%. Tuttavia, a volte cercare di ottenere una copertura del codice del 100% può essere un ottimo modo per rimuovere la cruft dalla base di codice. Non dimenticare che ci sono due modi per aumentare la copertura del codice: scrivere più test o estrarre il codice. Se il codice non è coperto perché è difficile da testare, ci sono buone possibilità che tu possa semplificare o refactoring per renderlo più facile da testare. Se è troppo oscuro preoccuparsi di testare, di solito c'è una buona probabilità che nient'altro nel codice lo stia usando.

38
RevBingo

La copertura del codice si avvicina al 100% asintoticamente. Di conseguenza, quell'ultimo 5% è probabilmente uno sforzo maggiore di quello che vale, dato che inizi a ottenere rendimenti sorprendentemente piccoli per lo sforzo speso.

14
Robert Harvey

La copertura è una metrica da tenere d'occhio, ma non dovrebbe essere l'obiettivo finale. Ho visto (e certamente scritto!) Un sacco di codice ad alta copertura - copertura al 100% (TDD, ovviamente), eppure:

  • i bug continuano a emergere
  • il design può ancora essere scadente
  • puoi davvero ucciderti sparando per un bersaglio con copertura arbitraria - scegli le tue battaglie: p

C'è un "The Way of Testivus" voce che penso sia appropriato fare riferimento qui :)

7
H.Y.

Solo il 20% della maggior parte del codice verrà eseguito l'80% delle volte . Un'analisi della copertura del codice non è molto utile a meno che non sia abbinata a un grafico di chiamata per determinare ciò che deve essere testato maggiormente. Questo ti dice dove è probabile che si trovino i tuoi casi Edge. Potresti trovare 100 test solo per quei casi Edge, che rappresentano meno del 5% del codice effettivo.

Quindi, assicurati di coprire il 100% del 20% che definisce i percorsi critici e almeno il 50% del resto (secondo il grafico della chiamata). Questo dovrebbe darti (approssimativamente) il 70% - 75% di copertura totale, ma varia.

Non perdere tempo a cercare di ottenere una copertura totale superiore al 70% lasciando i casi critici Edge senza controlli.

5
Tim Post

Utilizzare la copertura come guida per indicare le aree non testate. Piuttosto che avere un mandato per la copertura è più saggio capire il motivo del codice non coperto. Registrare una ragione per il deficit è una buona disciplina che consente di bilanciare i rischi.

A volte il motivo è meno desiderabile "ad es. a corto di tempo ", ma potrebbe essere OK per una versione anticipata. È meglio contrassegnare le aree a cui tornare per aumentare la copertura in un secondo momento.

Lavoro su software di volo critici in cui la copertura del 100% delle dichiarazioni è considerata adatta per sistemi non critici. Per i sistemi più critici controlliamo la copertura delle filiali/delle decisioni e utilizziamo una tecnica chiamata MC/DC che a volte non è abbastanza rigorosa.

Dobbiamo anche assicurarci di aver coperto anche il codice oggetto.

È un equilibrio tra rischio, nel nostro caso molto elevato, rispetto a valore/costo. È necessaria una scelta informata in base al rischio di perdere un bug.

4
Mark Fisher

Quando si iniziano a considerare modifiche che potrebbero influire sulle prestazioni, sulla sicurezza, sulla flessibilità o sulla manutenibilità del runtime per consentire una maggiore copertura del codice, è tempo di terminare la ricerca di una maggiore copertura del codice.

Ho progetti in cui quel punto è pari allo 0% perché la copertura è impossibile da calcolare senza danneggiare il design e altri progetti in cui è pari al 92%.

Le metriche di copertura del codice sono utili solo per sottolineare dove potresti aver perso alcuni test. Non ti dicono nulla sulla qualità dei tuoi test.

3
Bill

Mi piace molto la risposta di @ RevBingo perché suggerisce che la lotta per il 100% può farti ripulire o eliminare il codice inutilizzato. Quello che non ho visto nelle altre risposte è la sensazione di quando hai bisogno di una copertura elevata e quando non lo fai. Ho preso una pugnalata all'inizio. Penso che aggiungere dettagli a un grafico come questo sarebbe una ricerca più utile che trovare un numero di copertura del test che fosse giusto per tutto il codice.

100%

Per un'API pubblica, come le raccolte Java.util, che non è accoppiata a un database e non restituisce HTML, penso che il 100% di copertura sia un nobile obiettivo iniziale, anche se ti accontenti del 90-95% a causa di tempo o altro vincoli. L'aumento della copertura dei test dopo aver completato le funzionalità impone un livello di controllo più dettagliato rispetto ad altri tipi di revisione del codice. Se la tua API è popolare, le persone la useranno, la sottoclasseranno, la deserializzeranno, ecc. In modi che non puoi aspettarti. Non vuoi che la loro prima esperienza sia trovare un bug o supervisione del design!

90%

Per il codice di infrastruttura aziendale, che include strutture di dati e restituisce strutture di dati, il 100% è probabilmente ancora un buon obiettivo iniziale, ma se questo codice non è abbastanza pubblico da invitare un sacco di abusi, forse l'85% è ancora accettabile?

75%

Per il codice che accetta e restituisce stringhe, penso che i test unitari siano molto più fragili, ma possano comunque essere utili in molte situazioni.

50% o meno

Odio scrivere test per funzioni che restituiscono HTML perché è così fragile. Che cosa succede se qualcuno modifica CSS, JavaScript o l'intero blocco di HTML e inglese che restituisci non ha senso per gli utenti finali umani? Se riesci a trovare una funzione che utilizza molta logica di business per produrre un po 'di HTML, vale la pena testarlo. Ma la situazione inversa potrebbe non valere la pena testare affatto.

Vicino allo 0%

Per alcuni codici, la definizione di "corretto" è "ha senso per l'utente finale". Esistono test non tradizionali che puoi eseguire su questo codice come il controllo grammaticale automatico o HTML che convalida l'output. Ho anche impostato dichiarazioni grep per piccole incongruenze di cui comunemente cadiamo in preda al lavoro, come dire "Login" quando il resto del sistema lo chiama "Accedi". Quest'uomo non è rigorosamente un test unitario, ma un modo utile per rilevare i problemi senza aspettarsi risultati specifici.

Alla fine, però, solo un essere umano può giudicare ciò che è sensibile agli umani. I test unitari non possono aiutarti. A volte ci vogliono diversi umani per giudicarlo accuratamente.

Assoluto 0%

Questa è una categoria triste e mi sento meno una persona per scriverla. Ma in qualsiasi progetto sufficientemente ampio ci sono buchi di coniglio che possono succhiare persone settimane di tempo senza fornire alcun vantaggio commerciale.

Ho comprato un libro perché sosteneva di mostrare come deridere automaticamente i dati per i test di Hibernate. Ma ha testato solo le query Hibernate HQL e SQL. Se devi fare molto HQL e SQL, non stai davvero ottenendo il vantaggio di Hibernate. Esiste una forma di database in-memory di Hibernate, ma non ho investito il tempo per capire come usarlo efficacemente nei test. Se lo avessi eseguito, vorrei avere una copertura dei test elevata (50% -100%) per qualsiasi logica aziendale che calcola le cose navigando in un grafico a oggetti che causa l'esecuzione di alcune query da parte di Hibernate. La mia capacità di testare questo codice è quasi allo 0% in questo momento e questo è un problema. Quindi, migliora la copertura dei test in altre aree del progetto e provo a preferire funzioni pure rispetto a quelle che accedono al database, in gran parte perché è più facile scrivere test per quelle funzioni. Tuttavia, alcune cose non possono o non devono essere testate.

2
GlenPeterson

Il software space-critical richiede una copertura delle dichiarazioni del 100%.

All'inizio non ha senso. Tutti sanno che una copertura completa dei test non significa che il codice sia completamente testato e che non sia così difficile ottenere una copertura del 100% senza effettivamente testare l'applicazione.

Tuttavia, la copertura del 100% è un limite inferiore: sebbene la copertura del 100% non sia una prova di un software privo di bug, è certo che con una copertura minore il codice non è completamente testato e questo è semplicemente inaccettabile per il software critico per lo spazio.

2
mouviciel

Penso che dipenda dalla parte dell'applicazione che stai testando. Per esempio. per la logica aziendale o qualsiasi componente che comporti trasformazioni complesse di dati, mirerei a una copertura del 90% (il più elevata possibile). Ho spesso trovato piccoli ma pericolosi bug testando il più possibile il codice. Preferirei trovare tali bug durante i test piuttosto che lasciarli verificarsi sul sito di un cliente un anno dopo. Inoltre, un vantaggio di un'elevata copertura del codice è che impedisce alle persone di modificare il codice di lavoro troppo facilmente, poiché i test devono essere adattati di conseguenza.

D'altra parte, penso che ci siano componenti per i quali la copertura del codice è meno adatta. Ad esempio, durante il test di una GUI è molto tempo scrivere un test che copra tutto il codice che viene eseguito quando si fa clic su un pulsante per inviare l'evento ai componenti giusti. Penso che in questo caso sia molto più efficace utilizzare l'approccio tradizionale dell'esecuzione di un test manuale in cui è sufficiente fare clic sul pulsante e osservare il comportamento del programma (si apre la finestra di dialogo corretta? Viene selezionato lo strumento giusto ?).

1
Giorgio

Non ho un'alta opinione sull'uso della copertura del codice come misura per sapere quando la tua suite di test ha una copertura sufficiente.

Il motivo principale è perché se si dispone di un processo in cui si scrive prima un po 'di codice, quindi alcuni test, quindi si esamina la copertura del codice per scoprire dove si è perso un test, è il processo che deve essere migliorato. Se fai un vero TDD, allora hai una copertura del codice al 100% pronta all'uso (è vero, ci sono alcune banalità per le quali non collaudo). Ma se guardi la copertura del codice per scoprire cosa testare, probabilmente scriverai i test sbagliati.

Quindi l'unica cosa che puoi concludere dalla copertura del codice è che se è troppo basso, non hai abbastanza test. Ma se è alto, non c'è garanzia che tu abbia tutti i test giusti.

0
Pete