test di copertura realtà

Ci sono diversi modi per contare la copertura . Molti strumenti controllano quali linee sono eseguite dai test, ma non controllano che i test testino effettivamente qualcosa. Quindi in teoria potresti avere una copertura del 100% senza un singolo assert nei tuoi test, in effetti non testare nulla.

Tuttavia, affermi di avere una copertura del 70%, ma non riesci a cogliere il 70% dei problemi. Questo non è raro, dal momento che spesso un piccolo sottoinsieme del codice contiene la maggior parte dei problemi. Penso che Code Complete dica qualcosa sul fatto che il 20% del codice causa l'80% dei bug. Quest'area problematica nel tuo codice è solitamente complessa ed è per questo che solitamente non è testata. Quindi potresti avere una buona copertura del codice, ma la parte che non è coperta è la parte che ha più bisogno dei test.

In questo articolo Martin Fowler afferma che la copertura del test non è una buona misura per la qualità del codice. È un buon modo per trovare aree problematiche nel tuo codice. Quindi, nel tuo caso, supponendo che i tuoi test esistenti siano dei buoni test, ora dovresti essere in grado di individuare l'area problematica del tuo codice, il restante 30%.

Hai ragione, una metrica di copertura della linea non è garanzia di un test completo. La copertura del percorso (assicurando che ogni possibile percorso attraverso il codice venga esercitato almeno una volta) è molto più importante. Tuttavia, la copertura del percorso è molto più difficile da calcolare rispetto alla copertura del codice, e la copertura del codice è comunque utile (mentre una linea coperta non è necessariamente testata in modo completo, una linea che non è coperta in modo definitivo non è affatto testata) .

Devi prestare molta attenzione ai punti del tuo codice in cui il flusso dei rami di esecuzione. Le operazioni ternarie ( var = foo()? bar(): baz() ) dovrebbero essere di particolare interesse perché questi sono i punti che possono apparire completamente coperti anche quando viene seguito solo uno dei due percorsi di esecuzione disponibili.

Va anche detto che quando una parte del codice non è coperta dai test, è spesso perché è una parte difficile del codice da testare per vari motivi (logica estremamente complicata, dipendenze che non possono essere facilmente derise, dipendenti su eventi probabilistici, destinati a generare un output probabilistico, ecc.). Questo è spesso anche il tipo di codice in cui il test è più importante. Se un modulo ha una copertura del 95% del codice nei suoi test, non è ancora molto utile se il 5% scoperto è la parte del codice che è più probabile che porti bug.

Se il codice è ben progettato con i test in mente (coesivo, liberamente accoppiato, utilizza l'iniezione di dipendenza, ecc.) è quindi possibile una copertura del codice molto alta del 90% o superiore. Ma ovviamente, sebbene sia una metrica utile, una cifra di copertura elevata non significa che il tuo codice sia ben testato.

Non penso ci sia una correlazione generale tra copertura e bug rimasti. Tuttavia, se non hai eseguito una riga, non l'hai testata, quindi la copertura al 100% della linea non può far male se non ti lasci cullare da un falso senso di sicurezza.

Alla fine, a meno che tu non stia scrivendo un sistema con requisiti di affidabilità estremamente elevati, non mi dilungherò troppo sulla copertura grezza. Innanzitutto, prova i percorsi più importanti attraverso il programma. Quindi, per ogni problema che emerge, scrivi un test unitario prima di risolverlo. In questo modo, otterrai una copertura decente in un tempo ragionevole e sarai al sicuro dalle regressioni.