Qual è il vero sovraccarico di TDD una volta che tutto il team è abituato?

Ogni volta che esegui i test di unità, risparmi la quantità di tempo necessaria per testare manualmente il codice.

Il 30% al 50% del tempo che citi come richiesto per scrivere i tuoi test è anche ampiamente compensato dai vantaggi di avere un design software migliore (testabile).

Supponiamo che impieghi quattro volte il tempo per scrivere un test automatico così come per eseguire manualmente il test. Ciò significa che la quarta volta che esegui il test automatizzato, si ripaga da solo. Ogni volta che esegui il test automatico, è gratuito.

Questo è vero 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. Inoltre, il test automatizzato è più affidabile di una persona; eseguirà il test in esattamente allo stesso modo , ogni volta.

Avere test unitari significa che puoi rifattorizzare l'implementazione sottostante di un metodo (per le prestazioni o altri motivi), ei test unitari verificheranno che la funzionalità del metodo non sia cambiata. Questo è particolarmente vero per TDD, dove l'unità test specifica la funzionalità del metodo.

I've heard anywhere from 30-50% of your time is writing unit tests. However that doesn't take into account the time saved

Secondo la mia esperienza, è superiore al 50%.

Una volta che hai scritto il test, la soluzione tende a diventare molto facile. Quindi non penso che sia strano passare il 70% - 75% del tempo a scrivere test, ma stai spendendo molto meno tempo scrivendo il codice sotto test e spendendo praticamente meno tempo nel debugger.

Prima trovi un bug, più economico è da sistemare e TDD ti aiuta moltissimo. Ho lavorato su progetti in cui sono stati spesi gli ultimi 2 mesi (di un progetto di 8 mesi) per correggere bug, e quella fase sarebbe stata quasi completamente eliminata con TDD.

Per me, il vero valore è nella manutenzione. Ereditare un codice base con test rispetto a uno senza ti fa meno paura di apportare modifiche (probabilmente non hai infranto nulla se i test continuano a passare). Dal momento che non hai paura di apportare modifiche sei disposto a refactoring se qualcosa non va bene. Il che significa che il codice è più pulito, il design si adatta meglio e in teoria le modifiche possono essere applicate più rapidamente.

Il TDD viene spesso misurato sulla qualità del codice piuttosto che sul tempo e sui costi spesi. Tuttavia, con una migliore qualità del codice, gli sviluppatori e le persone che lavorano con loro possono lavorare meglio (meno tempo speso, meno costi coinvolti, più felici, ecc.). link

Scrivere i 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): link

• La scrittura di test funzionali può aiutare a individuare bug / problemi durante la fase di sviluppo . Supponi di avere una base di codice estesa. Con test / specifiche delle unità , devi solo vedere "Tutti i test superati" / "2 test non riusciti, vedere la riga xyz". Hai solo bisogno di un team di sviluppatori per sviluppare e testare entrambi. Senza test / specifiche delle unità , devi confrontare manualmente le istruzioni stampate con le dichiarazioni previste e manualmente tracciare quali metodi / classi hanno bug. Probabilmente hai bisogno di due team separati (sviluppatori e tester) per farlo.

• I test scritti aiutano gli sviluppatori a spiegare i progressi e i problemi affrontati.

• TDD aiuta a mantenere la manutenibilità, l'adattabilità e la flessibilità del codice. Incoraggia gli sviluppatori a scrivere piccoli pezzi testabili e li riunisce in blocchi più grandi testabili. Anche il contrario (parte della pratica di refactoring) funziona, a condizione che abbiamo scritto test solidi. 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 per scrivere il codice
• i compagni di squadra hanno suggerimenti per il miglioramento del codice
• dobbiamo spiegare / passare il nostro codice ad altre persone

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

Nel nostro caso, direi che è vicino al 40%. Tuttavia, non penso che abbiamo attraversato una fase in cui c'era più di questo. Abbiamo un generatore di codice che sputa sia uno scheletro di codice che viene arricchito dagli sviluppatori che una suite di test che si arricchisce. La maggior parte del nostro lavoro di test riguarda in realtà il rintracciamento (o la creazione) di 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 più difficile non bruciare la squadra facendo test senza cervello

le misure a breve termine sarebbero il ROI di automatizzazione dei test

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

i test hanno impiegato 28 minuti; sono passati tutti. eseguire manualmente gli stessi 40+ test di accettazione richiederebbe circa 6 ore.

un altro esempio: in una precedente iterazione avevo rimproverato uno degli scenari di test con un bug sottile che il test manuale probabilmente non avrebbe trovato (i test automatici eseguono controlli db sull'integrità che i tester manuali non fanno quasi mai). Ho dovuto eseguire lo scenario di test circa 50 volte prima che riuscissi a capirlo e correggerlo. eseguire manualmente le operazioni dello scenario di test richiederebbe circa 50 minuti. Quindi questo è di 41,6 ore / uomo di lavoro salvate in un giorno

non c'è modo di calcolare in anticipo il ROI dei test automatici, perché non puoi sapere esattamente quante volte dovrai eseguire i test.

ma secondo me, il ROI dei test automatici è quasi infinito

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

Il test dei componenti spesso fa un ottimo lavoro per un codice piuttosto banale, inoltre la modifica dell'implementazione è molto più economica perché i test sono solo accoppiati all'interfaccia.

La copertura completa con test unitari a grana fine ha un enorme sovraccarico per la modifica o il refactoring di un'implementazione, che è esattamente quello che pretendono di rendere più semplice.