Come quantificare il valore del test unitario [duplicato]

Il test delle unità è economico.

Ogni volta che esegui un test unitario, non hai dovuto pagare un tester per eseguire quel test manualmente, o eseguire il test da solo, a mano. Un computer può eseguire ripetutamente gli stessi test instancabili, con perfetta fedeltà (eseguendo il test esattamente nello stesso modo ogni volta).

Ogni volta che un test automatico rileva un errore mancato durante il refactoring, risparmi denaro impedendo al personale di controllo qualità di doverlo segnalare e indicando denaro e capitale della reputazione impedendo a tale bug di uscire dalla porta di un cliente.

I test automatici, in particolare i test delle unità, consentono di risparmiare denaro perché cattura rapidamente i bug. Più tardi viene trovato un errore, più è costoso (per ordine di grandezza):

Ecco un grafico delle mie esperienze con e senza test unitario. Quanti dei problemi sulla colonna di destra si applicano al tuo progetto?

                  With Unit Tests               Without Unit Tests
----------------- ----------------------------- -----------------------------
Development       Code/Test/Refactor            Cut and Paste/Hack 
Process           or Test/Code/Refactor         to minimize code change 
                                                and avoid complete retest

Module Coupling   Limited by continuous         Tangled due to need to
                  refactoring                   add features with minimal
                                                code change

Program Design    Evolving through Refactoring  Frozen due to risk of change

Velocity          Increasing as higher-level    Decreasing as code volume and
over Time         functions are factored out    coupling increase 

Bugs detected     Mostly by developer           Mostly by QA or Customer

Cost of bugs      Lower                         Higher

Dovresti essere in grado di puntare a casi specifici in cui il volume del codice è stato aumentato inutilmente o l'accoppiamento del modulo è stato aumentato per ridurre al minimo la necessità di ripetere il test. Tuttavia, se non credono di avere un problema e non sono interessati al miglioramento, potrebbe esserci poco da fare. Anche quando la manutenzione continua diventa antieconomica, possono credere che sia semplicemente la fine normale di tutti i progetti software.

Ho avuto successo nel migliorare i test solo quando i dirigenti sapevano che avrebbero dovuto sottoporsi a test, ma non erano sicuri di come farlo economicamente. Quando un'organizzazione non è interessata al miglioramento dei processi, è necessaria una grande pazienza per effettuare il cambiamento. Quanto sei paziente?

Una volta ho fatto una statistica su un numero di versioni e vari moduli di un sistema di grandi dimensioni, misurando sostanzialmente il numero di LOC di test unitario per codice funzionale LOC, rapportato al numero di bug rilevati durante il test manuale per LOC funzionale. Il risultato è stato simile a questo:

More Bugs
^
|
| +
|+    +  +     +
|   +    +          +   +       
|  +        +    +     +    + + 
|+     + +         +      +  +  +   +
|    +        +        +    +    + +
---------------------------------------> More Unit tests

Un'interpolazione lineare diceva che c'erano quasi il 50% in meno di bug nel codice con il maggior numero di test unitari, rispetto a quelli con nessuno. Ma come vedi, c'è una grande varianza, molto probabilmente legato alla complessità dei moduli, all'esperienza e alla competenza degli sviluppatori e alla maturità del codice.

Il test delle unità è inestimabile.

Ho molte esperienze con questo.

Quando per la prima volta non abbiamo adottato i test di unità, abbiamo impiegato la maggior parte del tempo a risolvere bug ea trattare con clienti pazzi perché le cose non funzionavano come previsto. Il debug del codice quando non hai idea di dove possa essere il bug è una seccatura, soprattutto perché devi prima riprodurlo per risolverlo.

Quando abbiamo deciso che era ora di iniziare a lavorare con UT, è cambiato tutto. Non abbiamo più ricevuto chiamate da pazzi clienti. Può sembrare eccessivo ma è andato esattamente così.

Con l'UT trovi gli errori prima dei tuoi clienti o del QA. Questo è un grosso problema.