Qual è l'effetto della creazione di unit test durante lo sviluppo sui tempi di sviluppo e sul tempo impiegato nelle attività di manutenzione?

Sono un consulente e presenterò test unitari a tutti gli sviluppatori sul sito del mio cliente. Il mio obiettivo è garantire che tutte le nuove applicazioni abbiano test unitari per tutte le classi create.

Il client ha un problema con costi di manutenzione elevati dovuti alla correzione di bug nelle applicazioni esistenti. Le loro applicazioni hanno una durata compresa tra 5-15 anni in cui aggiungono continuamente nuove funzionalità. Sono abbastanza fiducioso che trarranno grandi benefici dall'avvio dei test unitari.

Sono interessato all'effetto dei test unitari sui tempi e sui costi di sviluppo:

• Quanto tempo impiegherà la scrittura di unit test nell'ambito del processo di sviluppo?
• Quanto tempo verrà risparmiato nelle attività di manutenzione (test e debug) con buoni test unitari?

Sono disponibili statistiche su quanto tempo ci vorrà per sviluppare applicazioni durante la creazione di unit test durante lo sviluppo rispetto alla semplice codifica?

C'è qualche ricerca molto interessante su questo. Leggi il seguente white paper:

Realizzare il miglioramento della qualità attraverso lo sviluppo guidato da test: risultati ed esperienze di quattro team industriali

Il white paper e altre ricerche di uno dei suoi autori, Nachi Nagappan , sono discussi qui: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Lo studio e i suoi risultati sono stati pubblicati in un documento intitolato Realizzare il miglioramento della qualità attraverso lo sviluppo guidato da test: risultati ed esperienze di quattro team industriali, di Nagappan e dei colleghi di ricerca E. Michael Maximilien dell'IBM Almaden Research Center; Thirumalesh Bhat, principale responsabile dello sviluppo software presso Microsoft; e Laurie Williams della North Carolina State University. Ciò che il team di ricerca ha scoperto è che i team TDD hanno prodotto un codice che era dal 60 al 90 percento migliore in termini di densità dei difetti rispetto ai team non TDD. Hanno anche scoperto che i team TDD hanno impiegato più tempo per completare i loro progetti, dal 15 al 35 percento in più.

"In un ciclo di sviluppo di 12 mesi, il 35 percento è un altro di quattro mesi, il che è enorme", afferma Nagappan. "Tuttavia, il compromesso è che si riducono significativamente i costi di manutenzione post-rilascio, poiché la qualità del codice è molto migliore. Ancora una volta, queste sono le decisioni che i manager devono prendere: dove dovrebbero prendere il colpo? Ma ora hanno effettivamente dati quantificati per prendere quelle decisioni. "

Inoltre, Jason Gorman ha proposto un simile esperimento per la conferenza sull'artigianato del software quest'anno. Sta provando un esperimento per creare la stessa applicazione usando un approccio TDD e un approccio non TDD e ha recentemente scritto un blog sui suoi risultati :

Oltre 3 iterazioni, il tempo medio impiegato per completare il kata senza TDD è stato di 28m 40s. Il tempo medio con TDD è stato di 25m 27s. Senza TDD, in media ho fatto 5,7 passaggi (consegnando in test di accettazione). Con TDD, in media ho fatto 1.3 passaggi (in due tentativi, sono passati per la prima volta, in uno ci sono voluti 2 passaggi).

Ora, questo era un esperimento per bambini, ovviamente. E non esattamente le condizioni di laboratorio. Ma noto un paio di cose interessanti, tutte uguali.

Sarà interessante vedere i risultati completi di questo esperimento quando più persone lo eseguiranno.

Sono disponibili statistiche che mostrano per quante ore diminuisce la manutenzione quando si hanno (buoni) test unitari?

Dal white paper sopra:

I risultati dei casi studio indicano che la densità del difetto di pre-rilascio dei quattro prodotti è diminuita tra il 40% e il 90% rispetto a progetti simili che non hanno utilizzato la pratica TDD.