Qual è il vero overhead di TDD una volta che l'intero team è abituato?

Quale percentuale di tempo viene risparmiata e costata facendo TDD.

Presumo che questa percentuale di modifiche ai costi e ai premi durante un ciclo di vita dei progetti.

Immagino che la fase iniziale abbia molti più costi ma che siano state assegnate piccole ricompense. Più avanti (durante il factoring ) si ottiene il vantaggio dei test.

Ho sentito dire che dal 30 al 50% del tuo tempo sta scrivendo test unitari. Tuttavia, ciò non tiene conto del tempo risparmiato dalla scrittura di tali test.

Qual è l'esperienza di ognuno con questo?

Noi s

MODIFICA Qual è il tempo risparmiato e il costo del tempo? Nel bug fixing e refactorablity?

Ho sentito dire che dal 30 al 50% del tuo tempo sta scrivendo test unitari. Tuttavia, ciò non tiene conto del tempo risparmiato

Nella mia esperienza, è più del 50%.

Dopo aver scritto il test, la soluzione tende a diventare molto semplice. Quindi non penso che sia strano spendere il 70% - 75% del tuo tempo a scrivere test, ma stai spendendo molto meno tempo a scrivere il "codice di produzione" (codice in fase di test) e praticamente non dedichi tempo al debugger .

Prima trova un bug, più economico è riparare e TDD aiuta enormemente. Ho lavorato a progetti in cui gli ultimi 2 mesi (di un progetto di 8 mesi) sono stati spesi per correggere bug e quella fase sarebbe stata quasi del tutto eliminata con TDD.

Per me, però, il vero valore è nella manutenzione. Ereditare una base di codice con i test rende meno paura di modificarla. Ti senti come se non avessi rotto nulla quando i test ancora passano. Dato che non hai paura di apportare modifiche, sei disposto a riflettere se qualcosa non va. Ciò significa che il codice può essere reso più pulito, il design può adattarsi meglio e, in teoria, è possibile applicare le modifiche. Contrasta il fatto che con il codice voodoo tutti hanno paura di toccare.

Ogni volta che si eseguono i test unitari, si risparmia il tempo necessario per testare manualmente il codice.

Anche il 30-50% delle volte che ritieni necessario per scrivere i tuoi test è notevolmente compensato dai vantaggi di avere una progettazione software (testabile) migliore.

Diciamo che per scrivere un test automatizzato è necessario quattro volte più tempo che per eseguire manualmente il test. Ciò significa che la quarta volta che esegui il test automatico, si ripaga da solo. Ogni volta che esegui il test automatico dopo, è gratuito.

Ciò vale se il test è un test unitario automatizzato o un test funzionale automatizzato. Non tutti i test funzionali possono essere automatizzati, ma molti di loro possono farlo. Inoltre, il test automatizzato è più affidabile di una persona; eseguirà il test esattamente nello stesso modo , ogni volta.

Avere test unitari significa che è possibile riformattare l'implementazione sottostante di un metodo (per prestazioni o altri motivi) e i test unitari verificheranno che la funzionalità del metodo non sia cambiata. Ciò è particolarmente vero per TDD, in cui il test unitario specifica la funzionalità del metodo.

Il TDD viene spesso misurato in base alla qualità del codice piuttosto che al tempo e al costo spesi. Tuttavia, con una migliore qualità del codice, gli sviluppatori e tutte le persone che lavorano con loro possono lavorare meglio (meno tempo impiegato, meno costi, più felice, ecc.).http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Scrivere test è ottimo per aiutare ad automatizzare la verifica dei requisiti funzionali e non funzionali. Un video che mi ha convinto ad adottare TDD (in realtà BDD, TDD di alto livello): http://video.google.com/videoplay?docid=8135690990081075324#

• Scrivere test funzionali può aiutare a individuare bug / problemi all'inizio durante la fase di sviluppo . Supponiamo di avere una base di codice di grandi dimensioni. Con i test unitari / le specifiche , devi solo vedere "Tutti i test superati" / "2 test falliti, vedi riga xyz". Hai solo bisogno di un team di sviluppatori per eseguire sia lo sviluppo che i test. Senza test unit / specifiche , è necessario confrontare manualmente le istruzioni stampate con le dichiarazioni previste e tracciare manualmente quali metodi / classi hanno dei bug. Probabilmente avrai bisogno di due team separati (sviluppatori e tester) per farlo.

• Test scritti aiutano gli sviluppatori a spiegare progressi e problemi affrontati.

• TDD aiuta a soddisfare manutenibilità, adattabilità e flessibilità del codice. Incoraggia gli sviluppatori a scrivere piccoli pezzi testabili e metterli insieme in pezzi più grandi testabili. Anche il contrario (parte della pratica del refactoring) funziona, a condizione che abbiamo scritto prove solide. Di conseguenza, possiamo avere un codice modulare ben scritto.

Con TDD, siamo lieti di sapere quando:

• un cliente richiede modifiche ai requisiti (requisiti soddisfacenti)
• vengono scoperti modi migliori di scrivere codice
• i compagni di squadra hanno suggerimenti per migliorare il codice
• dobbiamo spiegare / passare il nostro codice ad altre persone

Il TDD può essere noioso perché il processo di sviluppo fa piccoli passi e quindi diventa così prevedibile.

Nel nostro caso, stimerei che sia vicino al 40%. Tuttavia, non credo che abbiamo attraversato una fase in cui non è stato più di questo. Abbiamo un generatore di codice che sputa sia uno scheletro di codice che viene elaborato dagli sviluppatori sia una suite di test che viene simulata allo stesso modo. La maggior parte del nostro impegno di test in realtà consiste nel rintracciare (o creare) dati di test appropriati per garantire una copertura completa.

le importanti misure a lungo termine non sono solo la qualità del codice e la sicurezza del codice, ma anche il fatto che non stiano esaurendo il team facendo test insensati

le misure a breve termine sarebbero il ROI dell'automazione dei test

ad esempio: la scorsa settimana ho apportato oltre 1000 modifiche al codice a causa di un cambiamento nell'architettura interna, ho avviato la suite di test automatizzata e sono andato a dormire.

l'esecuzione dei test ha richiesto 28 minuti; tutti sono passati. l'esecuzione manuale degli stessi oltre 40 test di collaudo richiederebbe circa 6 ore.

un altro esempio: in una precedente iterazione avevo rovinato uno degli scenari di test con un bug sottile che probabilmente i test manuali non avrebbero trovato (i test automatici eseguono controlli di integrità del db che i tester manuali non fanno quasi mai). ho dovuto eseguire lo scenario di test circa 50 volte prima di riuscire a capirlo e risolverlo. l'esecuzione manuale delle operazioni dello scenario di test richiederebbe circa 50 minuti. Quindi sono 41,6 ore-uomo di lavoro risparmiate in un giorno

non è possibile calcolare in anticipo il ROI dei test automatizzati, poiché non è possibile sapere con esattezza quante volte sarà necessario eseguire i test.

ma per me il ROI dei test automatizzati è quasi infinito

Può aiutare molto a limitare i test unitari a algoritmi complessi, casi in cui possono essere generati automaticamente e regressioni.

I test dei componenti spesso fanno un ottimo lavoro per codice piuttosto banale, inoltre cambiare l'implementazione è molto più economico perché i test sono solo accoppiati all'interfaccia.

La piena copertura con test unitari a grana fine ha un enorme sovraccarico per la modifica o il refactoring di un'implementazione, che è esattamente ciò che sostengono di rendere facile.