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?

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.

"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.

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.

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.

Se sei interessato anche alle prove contro i test unitari ecco un articolo ben studiato e studiato:

Perché la maggior parte dei test unitari è uno spreco di James O Coplien (guru magro e agile)

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.

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".

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 *

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

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à.

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.

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.

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.