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

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

"Basta" è quando puoi apportare modifiche al tuo codice con la certezza di non rompere nulla. Su alcuni progetti, che potrebbero essere del 10%, su altri, potrebbe essere del 95%.

Non raggiunge quasi mai il 100%. Tuttavia, a volte il tentativo di ottenere una copertura del 100% del codice può essere un ottimo modo per rimuovere cruft dal codice base. Non dimenticare che ci sono due modi per aumentare la copertura del codice: scrivi più test o elimina il codice. Se il codice non è coperto perché è difficile da testare, ci sono buone possibilità che tu possa semplificare o fare il refactoring per rendere più facile il test. Se è troppo oscuro preoccuparsi di testare, di solito c'è una buona probabilità che nessun'altra parte del codice lo stia usando.

La copertura del codice si avvicina al 100% asintoticamente. Di conseguenza, quell'ultimo 5% è probabilmente uno sforzo maggiore di quello che vale, poiché inizi a ottenere rendimenti incredibilmente bassi per lo sforzo impiegato.

Quando inizi a prendere in considerazione modifiche che influenzano le prestazioni in termini di runtime, sicurezza, flessibilità o manutenibilità per consentire una maggiore copertura del codice, è giunto il momento di porre fine alla ricerca di una maggiore copertura del codice.

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

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

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 delle chiamate per determinare cosa è necessario testare di più. Questo ti dice dove saranno probabilmente i tuoi casi limite. Potresti trovare 100 test solo per quei casi limite, 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 (in base al grafico delle chiamate). Questo dovrebbe ottenere (approssimativamente) il 70% - 75% di copertura totale, ma varia.

Non perdere tempo a cercare di ottenere oltre il 70% di copertura totale lasciando i casi critici senza controllo.

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

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

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

Dobbiamo anche assicurarci di aver coperto anche il codice dell'oggetto.

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

Il software "Space critical" richiede copertura al 100%.

All'inizio non ha senso. Tutti sanno che una copertura completa del test non significa che il codice sia stato completamente testato e che non sia così difficile ottenere una copertura del 100% senza testare realmente 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 lo spazio software.

Mi piace molto la risposta di @RobBingo perché suggerisce che la lotta verso il 100% può farti pulire o eliminare il codice inutilizzato. Quello che non ho visto nelle altre risposte è il senso di quando hai bisogno di una copertura elevata e quando non lo fai. Ho preso una pugnalata all'inizio di questo. Penso che l'aggiunta di dettagli a un grafico come questo sarebbe una ricerca più utile rispetto alla ricerca di un numero di copertura di prova corretto 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 la copertura al 100% sia un obiettivo di partenza nobile, anche se ti accontenti del 90-95% a causa di tempo o altri vincoli. Aumentare la copertura del test dopo aver completato la funzione impone un esame più dettagliato rispetto ad altri tipi di revisione del codice. Se la tua API è molto popolare, la gente la userà, la sottoclusterà, la deserializzerà, ecc. In modi che non puoi aspettarti. Non vuoi che la loro prima esperienza sia trovare un bug o una supervisione del design!

90%

Per il codice dell'infrastruttura aziendale, che accetta strutture dati e restituisce strutture dati, il 100% è ancora probabilmente 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 il test delle unità sia molto più fragile, ma può essere comunque utile in molte situazioni.

50% o meno

Odio scrivere test per funzioni che restituiscono HTML perché è così fragile. Cosa succede se qualcuno cambia il CSS, il JavaScript o l'intero blob di HTML e l'inglese che si restituisce non ha senso per gli utenti umani umani? Se è possibile trovare una funzione che utilizza un sacco di logica aziendale per produrre un po 'di HTML, questo potrebbe valere la pena di testare. Ma la situazione inversa potrebbe non valere la pena di testare affatto.

Vicino allo 0%

Per alcuni codici, la definizione di "corretto" è "ha senso per l'utente finale". Esistono test non tradizionali che è possibile eseguire su questo codice, ad esempio il controllo automatico della grammatica o la convalida HTML dell'output. Ho persino impostato le istruzioni grep per le piccole incongruenze che comunemente cadono in preda al lavoro, come dire "Login" quando il resto del sistema lo chiama "Accedi". Quest'uomo non è strettamente un test unitario, ma un modo utile per individuare i problemi senza aspettarsi output specifici.

In definitiva, però, solo un umano può giudicare ciò che è sensibile agli umani. I test unitari non possono aiutarti. A volte ci vogliono diversi umani per giudicare in modo accurato.

Assoluto 0%

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

Ho acquistato un libro perché ha affermato di mostrare come eseguire automaticamente il mocking dei dati per testare Hibernate. Ma ha testato solo Hibernate HQL e query SQL. Se devi fare un sacco di HQL e SQL, non hai davvero il vantaggio di Hibernate. C'è una forma di database in memoria di Hibernate, ma non ho investito il tempo per capire come usarlo efficacemente nei test. Se dovessi farlo funzionare, vorrei avere una copertura di prova elevata (50% -100%) per qualsiasi logica di business che calcola la roba navigando in un grafo di oggetti che fa in modo che Hibernate esegua alcune query. La mia capacità di testare questo codice è vicina allo 0% in questo momento e questo è un problema. Quindi migliorano la copertura dei test in altre aree del progetto e cerco di preferire le funzioni pure rispetto a quelle che accedono al database, in gran parte perché è più facile scrivere test per tali funzioni. Tuttavia, alcune cose non possono, o non dovrebbero essere testate.

Penso che dipenda dalla parte dell'applicazione che stai testando. Per esempio. per la logica aziendale o qualsiasi componente che implichi complesse trasformazioni di dati, punterei al 90% (il più alto possibile) della copertura. Ho trovato spesso piccoli ma pericolosi bug semplicemente testando la maggior parte del codice possibile. Preferisco trovare questi bug durante i test piuttosto che lasciarli presenti sul sito di un cliente un anno dopo. Inoltre, un vantaggio di una copertura di codice elevata è 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 dispendioso scrivere un test che copra tutto il codice che viene eseguito quando si fa clic su un pulsante per inviare l'evento ai componenti corretti. Penso che in questo caso sia molto più efficace utilizzare l'approccio tradizionale di eseguire 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? ?).

Non ho la grande 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 hai un processo in cui scrivi prima del codice, poi alcuni test e poi guardi la copertura del codice per scoprire dove hai perso un test, allora è il tuo processo che deve essere migliorato. Se fai il vero TDD, allora hai una copertura del codice del 100% fuori dalla scatola (devo ammettere che ci sono alcune banalità che non cerco). Ma se guardi la copertura del codice per scoprire cosa testare, allora 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 è garantito che tu abbia tutti i test giusti.