Il punto di TDD dal punto di vista del business non è tanto ridurre il tempo di correzione dei bug . Riduci lo sforzo di manutenzione, ma passi più tempo a correggere i difetti mentre scrivi il codice in primo luogo , perché al primo tentativo non ottieni mai le cose completamente corrette (se tu potessi, non lo faresti t testare affatto). A volte predomina un effetto, a volte l'altro.
Tuttavia , TDD è ancora utile perché spostare lo sforzo in anticipo rende il processo più economico. Quanto prima si rileva un errore, tanto meno è da risolvere. Lo prendi mentre è nella tua testa, non hai perso tempo a scriverlo. Se lo prendi prima del check-in, non perdere tempo a ripristinare il commit. Se la prendi prima che il QA ci metta le mani sopra, non hai perso tempo. (Se non lo lo prendi fino a quando non è vivo con un cliente, fissarlo diventa orribilmente costoso perché hai perso tempo, il tempo dello staff di supporto e il tuo tempo che avrebbe potuto essere utilizzato per migliorare la base del codice.)
A mio parere, i flussi di lavoro basati sui test non riducono riducono gli errori poiché spostano l'occorrenza di errori da posizioni più costose a meno costose nel processo di sviluppo. E questo ha un valore commerciale sufficiente a giustificare il modo di far girare le cose.