Copertura del codice nel test unitario

Question

Riguarda le librerie .NET (DLL).

Quali sono le opzioni per misurare il codice coperto da casi di test unitari? Ne vale davvero la pena (misurare la copertura del codice)? Mi chiedo che potrebbe essere troppo facile coprire il 70% del codice e quasi impossibile andare oltre il 90%.

[EDIT] Un'altra domanda interessante (posta da & Quot; E Rolnicki & Quot;) è: Che cosa è considerata una percentuale di copertura ragionevole?

Answer 1

NCover (sia quello commerciale che quello open source con lo stesso nome) e lo strumento di copertura del codice in Visual Studio sono praticamente i tuoi strumenti principali nel mondo della SM.

La copertura del codice è una metrica inversa. Non ti mostra davvero quale codice è adeguatamente testato. Come accennato da Nick, puoi fare un test su quella copertina ma non testare molto. La copertura del codice ti dice invece quale area del tuo codice non ha assolutamente test. Da lì, puoi decidere se ha senso scrivere test per questo codice.

In generale, penso che dovresti fare la copertura del codice poiché non richiede molto sforzo per la configurazione e almeno ti dà più informazioni sul tuo codice rispetto a quello che avevi prima.

Sono d'accordo sul fatto che ottenere l'ultima frazione di codice sia probabilmente la più difficile e potrebbe esserci un punto in cui il ROI su di esso non ha senso.

Answer 2

NCover ti aiuterà a mostrare la tua copertura. La copertura è incredibilmente utile, purtroppo può ovviamente essere giocata. Se hai sviluppatori cattivi che coprono il codice solo per aumentare la percentuale di età, sì, alla fine sarà inutile e nasconderà aree scoperte. Una volta licenziato quelle persone, puoi risolverlo e tornare a informazioni utili. Stabilire obiettivi di copertura irraggiungibili è un modo sicuro per ottenere una cattiva copertura.

Answer 3

Se stai sviluppando Test Driven Development, il tuo codice dovrebbe colpire almeno il 70% senza provare. Alcune aree in cui non puoi o non ha senso avere una copertura di prova, ecco dove gli attributi NoCoverage per NCover sono utili (puoi contrassegnare le classi da escludere dalla copertura del codice).

La copertura del codice non dovrebbe essere rispettata religiosamente, dovrebbe semplicemente essere un modo utile per darti suggerimenti su aree che hai perso con i test. Dovrebbe essere tuo amico, non nazista!

Answer 4

Ci sono due cose da prendere in considerazione quando si guarda la copertura del codice.

1. La copertura del codice è una battaglia di rendimenti decrescenti: oltre un certo punto ogni percentuale aggiuntiva produce meno valore. Alcuni codici (come le librerie di base) dovrebbero essere coperti al 100%, mentre il codice / interazione UI può essere molto difficile da coprire.
2. La copertura del codice è una metrica che può essere ingannevole: la copertura del codice al 100% non equivale a un'applicazione completamente testata.

Prendi ad esempio questo frammento:

if (a == 2)
{
    do_A_Stuff();
}

if (b == 3)
{
    do_B_Stuff();
}

Esegui un test in cui a = 2 e un secondo test in cui b = 3. È una copertura del codice del 100%. Ma cosa succede quando con un test in cui a = 2 & Amp; b = 3? Questi sono & Quot; Relazioni variabili & Quot; e può portare a un'eccessiva fiducia nelle metriche di copertura.

Answer 5

Non l'ho usato personalmente, ma uno dei miei colleghi giura di nCover ( http: // www .ncover.com / ).

Per quanto riguarda la copertura, almeno in Ruby il 70% è facile, il 90% è fattibile e il 100% raramente è possibile.

Answer 6

Visual Studio Team System Developer Edition include la copertura del codice. Questo può essere incluso durante l'esecuzione di unit test.

Apri .testrunconfig e seleziona per quali assembly vuoi i dati.