Esistono prove concrete del ROI dei test unitari?


127

Il test unitario mi sembra fantastico, ma non sono sicuro che dovrei dedicare del tempo a impararlo davvero a meno che non riesca a convincere gli altri che ha un valore significativo. Devo convincere gli altri programmatori e, soprattutto, i bean-counter nella gestione, che tutto il tempo extra impiegato per apprendere il framework di test, scrivere test, tenerli aggiornati, ecc. Pagherà per se stesso, e poi alcuni.

Che prova c'è? Qualcuno ha effettivamente sviluppato lo stesso software con due team separati, uno usando unit test e l'altro no, e confrontato i risultati? Ne dubito. Devo solo giustificarlo con "Cerca su Internet, tutti ne parlano, quindi deve essere la cosa giusta da fare"?

Dove sono le prove concrete che convinceranno i laici che i test unitari valgono lo sforzo?

Risposte:


98

Sì. Questo è un link a uno studio di Boby George e Laurie Williams alla NCST e un altro di Nagappan et al. Sono sicuro che ce ne sono altri. Le pubblicazioni del Dr. Williams sui test possono fornire un buon punto di partenza per trovarle.

[EDIT] I due articoli sopra menzionano specificamente il TDD e mostrano un aumento del 15-35% nei tempi di sviluppo iniziale dopo l'adozione del TDD, ma una riduzione del 40-90% dei difetti di pre-release. Se non riesci ad accedere alle versioni full text, ti suggerisco di utilizzare Google Scholar per vedere se riesci a trovare una versione disponibile al pubblico.


14
Il primo studio confronta agile + TDD con progetti a cascata, i suoi risultati sarebbero più rilevanti se avesse confrontato due team agili. Il secondo studio menziona altri studi che hanno riscontrato un bonus di qualità scarso o nullo per i progetti TDD. E quando si confrontano le stime della direzione sui tempi supplementari necessari per TDD, le stime sono significativamente più elevate per i due team con una competenza di dominio elevata, ma hanno anche una copertura di test inferiore del 20%. Ciò conferma la mia esperienza, trovo la sicurezza molto più importante nei sistemi con cui non ho ancora lavorato, mentre i test sono un ostacolo per tutto il resto.
LearnCocos2D

Nessuno degli studi confronta il modello di processo comparabile con solo il cambiamento di testmethofology. Vale a dire passare il tempo impiegato su UT in realtà meglio speso ad es. test di sistema. Allo stato attuale potrebbe anche essere lo studio "se testiamo in modo più intelligente aiuta".
Rune FS

1
E se il costo per correggere i bug post release fosse lo 0,01% dello sviluppo totale? TDD sarebbe un investimento terribile in quel caso. E se i bug sono pochi? Questi% s non significano nulla senza contesto. Per essere onesti, devo ancora leggere l'intero studio. Ma allo stato attuale il tuo post è utile (buoni collegamenti) ma non risponde alla domanda relativa al ROI, all'IMO.
Instine,

1
@Instine Fortunatamente (?) Ci sono buone prove che non è così. La correzione di bug post-release è esponenzialmente più costosa rispetto ai bug trovati all'inizio dello sviluppo (che è ciò che fa TDD). In tale contesto, sembra improbabile un costo dello 0,01% dello sviluppo totale per tutti i bug post-release. (Per i dettagli vedere Codice completo , in particolare Boehm e altri , "Comprensione e controllo dei costi del software", IEEE Trans Softw Eng (1988)).
Konrad Rudolph,

Vale probabilmente la pena notare che il primo studio ha una dimensione del campione di 24 programmatori (che lavorano in coppia, quindi 12 team). Non sono sicuro di quale sarebbe una dimensione del campione statisticamente valida, ma questi sembrano bassi. Forse qualcun altro lo sa?
Zachary Yates,

29

"Devo convincere gli altri programmatori e, soprattutto, i bean-counter nella gestione, che tutto il tempo extra impiegato per apprendere il framework di test, scrivere test, tenerli aggiornati, ecc. Pagherà per se stesso, e poi alcuni. "

Perché?

Perché non farlo, in modo discreto e discreto. Non devi farlo tutto in una volta. Puoi farlo in piccoli pezzi piccoli.

L'apprendimento del framework richiede pochissimo tempo.

Scrivere un test, solo uno, richiede pochissimo tempo.

Senza test unitari, tutto ciò che hai è un po 'di fiducia nel tuo software. Con un test unitario, hai ancora la tua sicurezza, oltre alla prova che almeno un test ha superato.

Questo è tutto ciò che serve. Nessuno deve sapere che lo stai facendo. Fallo e basta.


9
I contatori di bean non potevano distinguere un test unitario dal resto del codice se le loro vite dipendessero da esso. Appoggio il suggerimento di farlo. C'è un avvertimento, però: se non sei solo, hai bisogno che i tuoi colleghi sviluppatori adottino questa pratica. In caso contrario, interromperanno involontariamente i test.
Thomas Eyde,

Fallo e non dirglielo, e vendi l'idea ai tuoi college durante la pausa caffè ;-)
Johan,

3
Perché verrai licenziato se non rispettassi costantemente le tue scadenze?
Andrew,

3
@Neko: i test unitari non aggiungono un "po 'di sovraccarico". Essi riducono il carico di lavoro complessivo, impedendo tutta una marea di errori stupidi. Il lavoro non cresce; passa semplicemente dalla natura al cattivo codice, ai buoni test unitari e al buon codice.
S. Lott

1
I contatori di bean vogliono che i loro ingegneri forniscano solide soluzioni ai problemi del dominio. Puoi semplicemente scrivere test come parte della tua soluzione. Non se ne accorgeranno nemmeno. Se ti chiedono, puoi semplicemente dire loro che ci stai dedicando più tempo per assicurarti che sia robusto e che non richieda una rielaborazione. Se SUGGERISCI scrivendo loro dei test unitari stai chiedendo la loro approvazione su qualcosa di cui non sanno nulla.
Yorkshireman

16

Ho un approccio diverso a questo:

Che garanzia hai che il tuo codice è corretto? O che non infrange l'ipotesi X quando qualcuno nella tua squadra cambia func1 ()? Senza test unitari che ti mantengono "onesto", non sono sicuro che tu abbia molte garanzie.

L'idea di mantenere aggiornati i test è interessante. I test stessi non devono spesso cambiare. Ho 3 volte il codice di prova rispetto al codice di produzione e il codice di prova è stato modificato molto poco. È, tuttavia, ciò che mi consente di dormire bene la notte e la cosa che mi consente di dire al cliente che ho fiducia che posso implementare la funzionalità Y senza rompere il sistema.

Forse nel mondo accademico ci sono prove, ma non ho mai lavorato da nessuna parte nel mondo commerciale dove qualcuno avrebbe pagato per un simile test. Posso dirti, tuttavia, che ha funzionato bene per me, ci è voluto poco tempo per abituarmi al framework di test e scrivere test mi ha fatto davvero pensare alle mie esigenze e al design, molto più di quanto abbia mai fatto quando ho lavorato in team che non ha scritto test.

Ecco dove si ripaga da solo: 1) Hai fiducia nel tuo codice e 2) Riscontri i problemi prima di quanto faresti altrimenti. Non è necessario il QA ragazzo dire "ehi, non si sono preoccupati limiti-checking la funzione XYZ (), vero? Lui non viene a scoprire che errore, perché si trovato un mese fa. Questo è positivo per lui, buono per te, buono per l'azienda e buono per il cliente.

Chiaramente questo è aneddotico, ma ha funzionato a meraviglia per me. Non sono sicuro di poterti fornire fogli di calcolo, ma il mio cliente è felice e questo è l'obiettivo finale.


Il mio addetto al controllo qualità era piuttosto acuto, ma non stava guardando il codice, ma era facile dire che i limiti non erano stati controllati.
itsmatt

Totalmente d'accordo sui test unitari che ti costringono a pensare di più al tuo design e alla tua correttezza piuttosto che al codice incautamente
chakrit

7
I clienti non ci pagano per scrivere test. Inoltre, non ci pagano neanche per scrivere il codice. Ci pagano per risolvere i loro problemi e, di fronte, scommetto che vogliono anche che i problemi rimangano risolti. Date le prove, è incredibile che i clienti non vogliano proteggere il proprio investimento.
Thomas Eyde,

10

Abbiamo dimostrato con prove concrete che è possibile scrivere software scadente senza Unit Testing. Credo che ci siano anche prove di software scadenti con Unit Testing. Ma questo non è il punto.

Unit Testing o Test Driven Development (TDD) è una tecnica di progettazione, non una tecnica di prova. Il codice scritto test driven sembra completamente diverso dal codice che non lo è.

Anche se questa non è la tua domanda, mi chiedo se sia davvero il modo più semplice di percorrere la strada e rispondere alle domande (e portare prove che potrebbero essere sfidate da altri rapporti) che potrebbero essere poste in modo sbagliato. Anche se trovi prove concrete per il tuo caso, qualcun altro potrebbe trovare prove concrete contro.

È compito dei contatori di fagioli determinare come dovrebbero lavorare le persone tecniche? Stanno fornendo gli strumenti più economici in tutti i casi perché credono che tu non abbia bisogno di strumenti più costosi?

Questa argomentazione viene vinta in base alla fiducia (uno dei valori fondamentali delle squadre agili) o persa in base al potere di ruolo della parte vincente. Anche se i sostenitori del TDD vincessero in base al potere di ruolo, lo considererei perduto.


13
ascolta, ascolta :) Molte delle prove concrete per TDD provengono anche da team di grande esperienza che già ottenevano buoni risultati senza di essa. TDD ha appena migliorato i risultati anziché crearli dal nulla. Il vero ROI sta assumendo programmatori decenti e permettendo loro di decidere come fare le cose.
workmad3

"È compito dei contatori di fagioli determinare come dovrebbero lavorare i tecnici?" -> tutte le decisioni aziendali si riducono al denaro. Comunque, buona risposta, +1
jcollum,

@jcollum ma il modo in cui svolgi il tuo lavoro non ha nulla a che fare con i soldi e se desideri che uno sia responsabile di una responsabilità, lascia che decidano come fanno ciò che hai chiesto loro
Rune FS

TDD non è una tecnica di progettazione, è solo una tecnica di codifica. blog.ploeh.dk/2010/12/22/TheTDDApostate Molti commentatori non sono d'accordo sul fatto che TDD implichi il refactoring (che è una tecnica di progettazione) ma il refactoring non implica TDD. Si può refactoring senza test, il refactoring di grandi dimensioni complesse influisce comunque sui test unitari, vale a dire che anche i test devono essere rifattorizzati in modo da poter diventare non validi / anche falsi verdi; i refactoring più semplici non influenzano i test ma il rischio di errore è inferiore, poiché il refactoring è semplice.
KolA

@KolA bene, con il riflesso di 10,5 anni dopo questa risposta, potrei definirlo un po 'più difensivo oggi, ma comunque: non sostengo che TDD sia l'unica tecnica di progettazione di cui tu abbia mai bisogno e Mark si apre con una buona tecnica di progettazione prima di concludere che non lo è affatto. Indebolirei la sua opinione e direi che non deve essere l' unica tecnica di progettazione. Ogni codice che io abbia mai scritto TDD sembra diverso dal codice che ho scritto senza. Lo definirei un risultato del design. Lavoro meglio con lavagna, discussioni e altri strumenti, oltre a TDD. Ma grazie per il link
Olaf Kock


6

Più sul TDD che sui rigorosi test unitari, ecco un link al Realizzare il miglioramento della qualità attraverso lo sviluppo guidato dai test: risultati ed esperienze di quattro team di gruppi industriali , di Nagappan, E. Michael Maximilien, Thirumalesh Bhat e Laurie Williams. articolo pubblicato dal gruppo Microsoft Empirical Software Engineering and Measurement (ESM) e già menzionato qui.

Il team ha scoperto che i team TDD hanno prodotto un codice compreso tra il 60% e il 90% migliore (in termini di densità dei difetti) rispetto ai team non TDD. Tuttavia, i team TDD hanno impiegato tra il 15% e il 35% in più per completare i loro progetti.


5

Ecco una lettura fantastica e divertente di un ragazzo che cambia la sua compagnia dall'interno. Non è limitato a TDD. http://jamesshore.com/Change-Diary/ Nota che non ha persuaso i "contatori di fagioli" per un po 'di tempo e ha invece "tattiche di guerriglia".


il link sembra interessante ... la pena di verificare Re: organizzazioni che cambiano funzionano i processi ...
brutto pastosa

5

Solo per aggiungere ulteriori informazioni a queste risposte, ci sono due risorse di meta-analisi che possono aiutare a capire la produttività e gli effetti di qualità sul background accademico e industriale:

Introduzione dell'editor degli ospiti: TDD — The Art of Fearless Programming [ link ]

Tutti i ricercatori sembrano concordare sul fatto che TDD incoraggi una migliore concentrazione delle attività e copertura dei test. Il semplice fatto di più test non significa necessariamente che la qualità del software sarà migliore, ma la maggiore attenzione del programmatore per la progettazione dei test è comunque incoraggiante. Se consideriamo i test come il campionamento di una popolazione molto ampia di potenziali comportamenti, più test significano un campione più approfondito. Nella misura in cui ogni test può trovare un problema importante che nessuno degli altri riesce a trovare, i test sono utili, soprattutto se è possibile eseguirli a buon mercato.

Tabella 1. Un riassunto degli studi empirici selezionati sullo sviluppo guidato dai test: partecipanti al settore *

https://www.computer.org/cms/Computer.org/dl/mags/so/2007/03/figures/s3024t1.gif

Tabella 2. Una sintesi degli studi empirici selezionati di TDD: partecipanti accademici *

inserisci qui la descrizione dell'immagine

Gli effetti dello sviluppo guidato dai test su qualità esterna e produttività: una meta-analisi [ link ]

Astratto:

Questo documento fornisce una meta-analisi sistematica di 27 studi che studiano l'impatto dello sviluppo guidato dai test (TDD) sulla qualità e sulla produttività del codice esterno.

I risultati indicano che, in generale, il TDD ha un piccolo effetto positivo sulla qualità ma un effetto poco o per nulla percepibile sulla produttività. Tuttavia, l'analisi dei sottogruppi ha riscontrato che sia il miglioramento della qualità che il calo della produttività sono molto maggiori negli studi industriali rispetto agli studi accademici. Un calo maggiore della produttività è stato riscontrato in studi in cui la differenza nello sforzo di test tra il TDD e il processo del gruppo di controllo era significativa. Un maggiore miglioramento della qualità è stato riscontrato anche negli studi accademici quando la differenza nello sforzo di test è notevole; tuttavia, non è stato possibile trarre conclusioni sugli studi industriali a causa della mancanza di dati.

Infine, è stata studiata l'influenza dell'esperienza degli sviluppatori e della dimensione dell'attività come variabili del moderatore, ed è stata trovata una correlazione positiva statisticamente significativa tra la dimensione dell'attività e l'entità del miglioramento della qualità.


4

Bene, ci sono alcune grandi aziende che richiedono di utilizzare i test unitari, ma se sei una piccola azienda perché imitare quelle grandi?

Per me, quando ho iniziato con i test unitari, molti anni fa (oggi usiamo principalmente il modello comportamentale ) è stato perché non riuscivo a controllare tutto il percorso in un'unica applicazione.

Ero abituato a programmare prima un REPL e quindi un REPL, quindi quando ho ottenuto Unit Test (un test per ogni funzione) era come riportare un REPL in linguaggi che erano molto compilati. Ha riportato il divertimento in ogni riga di codice che ho scritto. Ho sentito Dio. Mi è piaciuto. Non avevo bisogno di un rapporto per dirmi che ho iniziato a scrivere codice migliore più velocemente. Il mio capo non aveva bisogno di un rapporto per accorgersene perché a causa di cose pazze all'improvviso non abbiamo mai perso una scadenza. Il mio capo non aveva bisogno di un rapporto per notare che il numero di bug "semplici" scendeva da (a molti) a quasi zero a causa di questa strana cosa di scrivere codice non produttivo.

Come ha già scritto un altro poster, non si utilizza TDD per il test (verifica). Lo scrivi per catturare le specifiche, il comportamento di ciò che la tua unità (oggetto, modulo, funzione, classe, server, cluster) funziona.

Ci sono molti fallimenti e storie di successo nel passaggio a un diverso modello di sviluppo software in molte aziende.

Ho appena iniziato a usarlo ogni volta che avevo qualcosa di nuovo da scrivere. C'è un vecchio detto che può essere piuttosto difficile da tradurre in inglese ma:

Inizia con qualcosa di così semplice che non ti accorgi di farlo. Quando ti alleni per una maratona, inizia a camminare per 9 metri e corri per 1 metro, ripeti.


Quindi, dovrei farlo? È garantito che funzioni e non importa se nessun altro lo fa con me?
corvo,

In realtà, questo è un test Joel: joelonsoftware.com/articles/fog0000000043.html . Mi sembra che potresti avere più problemi della mancanza dello studio sul premio Nobel per lo unit test
Jonke,

4

Ci sono statistiche che dimostrano che la correzione di un bug trovato nel test unità / integrazione costa molte volte meno rispetto alla correzione una volta che è sul sistema live (si basano sul monitoraggio di migliaia di progetti di vita reale).

Modifica : ad esempio, come sottolineato, il libro " Codice completo " riporta tali studi (paragrafo 20.3, "Efficacia relativa delle tecniche di qualità"). Ma c'è anche una ricerca privata nel campo della consulenza che lo dimostra.


1
Questo è trattato nel Codice completo di Steve McConnell , che è un libro che probabilmente vorresti avere nella tua libreria per altri motivi.
Robert Rossney,

Ciò non è correlato al metodo di prova ma a quando nel processo viene segnalato un bug e inoltre il tempo sarebbe meglio speso a trovare bug nelle specifiche poiché il costo di correggerli quando li trovo durante lo sviluppo è segnalato fino a 1000 volte più costoso (un fattore 10 per fase di sviluppo)
Rune FS

OTOH, se risolvi solo i problemi che le persone incontrano effettivamente nelle situazioni della vita reale, probabilmente finisci per dover correggere molti meno bug. Inoltre, non è chiaro per me che correggere i bug in precedenza sia davvero più economico, poiché rilevare un bug in una specifica potrebbe richiedere molto più sforzo rispetto al rilevamento dello stesso bug nell'implementazione e il rilevamento del bug fa parte del costo della correzione. Questa è una di queste cose in cui tutti credono solo perché sembra evidente, ma non ho mai visto uno studio del suono che mostrasse l'effetto.
LKM,

0

Ho un set di punti dati per questo - da un'esperienza che mi ha venduto durante i test unitari.

Molte lune fa ero un neolaureato che lavorava su un grande progetto VB6 e ho avuto occasione di scrivere una grande quantità di codice di procedura memorizzata. Del sottosistema che stavo scrivendo costituiva circa 1/4 dell'intera base di codice - circa 13.000 LOC su 50K circa.

Ho scritto una serie di test unitari per le procedure memorizzate, ma il test del codice UI VB6 UI non è realmente possibile senza strumenti come Rational Robot; almeno non era allora.

Le statistiche del QA sul pezzo erano che circa 40 o 50 difetti sono stati sollevati sull'intero sottosistema, due dei quali originati dalle procedure memorizzate. Questo è un difetto per 6.500 righe di codice contro 1 per 1.000-1.200 o giù di lì sull'intero pezzo. Ricordare inoltre che circa i 2/3 del codice VB6 era un codice standard per la gestione e la registrazione degli errori, identico in tutte le procedure.

Senza troppe operazioni manuali, è possibile attribuire almeno un miglioramento dell'ordine delle magnitudini nelle percentuali di difetto al test unitario.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.