Il costo del test di unità
test di unità è un tema ricorrente per me in queste ultime settimane; tra parlando StackOverflow e altri forum e le prove che scrivo per due progetti in corso, Ho chiesto alcune domande circa il costo effettivo del test di unità.
Questo è particolarmente un articolo di Thomas Brandt (Tedesco: “TDD in der (il mio) Pratica - desiderio e realtà”) che mi ha fatto pensare seriamente. Brandt descrive nel suo articolo abbastanza bene infatti questo divario tra teoria e pratica del Test Driven Development. Di punto in bianco, Piuttosto, essa aderisce ai principi del TDD;
Devo dire innanzi tutto che Test Driven Development, in particolare il principio della "prima prova", è piuttosto “sexy” sviluppare. Si può certamente migliorare l'architettura del software e ci impedisce di portare a termine determinate (piccoli) errori.
— traduzione relativamente libera di circa T. Brandt
Si ritiene, pertanto, TDD come un potente strumento – almeno da un sistema puramente accademico. Ma il risultato immediato è un dubbio;
La questione è semplicemente: a che prezzo?
Come già detto, ad eccezione di T. Brandt e io, molte altre persone sembrano chiedere, e la domanda più frequente è la seguente: È che l'uso di test di unità che fa software davvero meglio, ed è che gli sforzi per investire siano realistiche?
Condensato, la questione si riduce ad un semplice:
Mi è costato quanto l'unità di test?
Spesso la questione coinvolge, che chi rileva che i test unitari sono troppo costosi, di applicare uniformemente. Mi ricordo di una discussione che ho avuto circa il valore di una copertura totale di prova, oltre l'ideale teorico. Segnalato sforzi per fornire ho detto “non” al momento.
Ad oggi penso che tutte queste domande vengono poste semplicemente male, perché non si conosce il costo del test di unità è importante, di più:
Come faccio a pagare l'omissione di test di unità?
Ed ecco la mia risposta, illustrato con un esempio concreto;
Uno dei miei progetti attuali comprendono un gran numero di componenti distribuiti. Ho scoperto un errore nel progetto, che mi ha costretto a effettuare il refactoring di entrambe le classi. Tutti mi ci sono voluti circa 1 ora. Lancio di unit test? Informazioni su 30 secondo. 30 secondo, ho scoperto che alcuni comportamenti non erano, come inizialmente previsto. Mi ci sono voluti circa 20 minuti per le correzioni. Scrivere i test mi è costato circa 45 min.
Il bilancio è di circa due ore.
Senza unit test, Io probabilmente non si sarebbe accorto alcuni degli errori immediatamente. Avrei avuto 1 tempo di refactoring, su un più o meno determinabile, certamente su più giorni, per correggere i problemi di passare inosservati quando si cambia. La probabilità che questa volta va ben oltre un'ora è relativamente elevato (debug “mano”, ricreare le condizioni in applicazioni multi-threaded, ecc…).
Per parte mia, Trovo che per calcolare un tempo definito (prove hanno che coprono una parte realistica del software – non 100%) più interessante è che la navigazione nel buio come praticato.
Esperimento! 
)