Molto spesso i vantaggi dell'uso di TDD sono considerati come guadagni "a lungo termine" - il codice complessivo sarà meglio strutturato, più testabile, in generale meno bug segnalati dai clienti, ecc.
Tuttavia, dove sono i vantaggi a breve termine dell'uso di TDD? Ci sono quelli che sono effettivamente tengibili e facilmente misurabili?
È importante avere un vantaggio a breve termine ovvio (o addirittura non ovvio da quantificabile), se i guadagni a lungo termine sono misurabili?
Ci sono alcuni benefici a breve termine per TDD, alcuni più misurabili di altri. Eccone alcuni in cima alla mia testa:
Pulisci codice, seguendo buoni principi SOLID . Cioè se mantieni i tuoi test puliti come il tuo codice e evitare il codice di test ibrido sporco , il codice tenderà a seguire SOLID. Il codice pulito è più facile da leggere ed è più facile mantenere il codice dall'inizio. Le ore di lavoro vengono salvate durante la manutenzione, ma a breve termine: otterrai un codice più pulito più veloce (perché hai alcuni test per il backup).
Test di regressione dall'inizio; l'hai rotto e lo sai a riguardo ... presto. Sostenuto da un server CI, questo ti farà risparmiare un po 'di capelli. Le ore di lavoro per correggere un bug regredito che scoprirai presto senza test sono difficili da misurare, ma lascia solo dire che ci sono molte ore di lavoro.
Consente di eseguire il refactoring senza troppe congetture. Se hai fatto una suite di test per una lezione, rifattarla (come estrarre metodi, usare altre strutture di dati, estrarre classi) sarà facile perché hai definito i test dall'inizio. Ciò che impiegherebbe giorni per refactoring di una classe ne richiederà meno di uno; e puoi farlo subito se hai fatto i test da prima.
Il design guidato dal test consente di correggere la duplicazione del codice in anticipo. Almeno se sei un programmatore osservatore; perché il test con codice duplicato (sia nel codice di test che nel codice di produzione) diventa rapidamente un'attività noiosa. Più intelligente sei con il tuo codice di test, meglio sarà. Meno codice, meno problemi, più ore di lavoro salvate.
EDIT aggiunto anche da Frank Shearar, che sono d'accordo:
At any point you have working code (except the test case you're currently working with).
Trovare bug o problemi di progettazione all'inizio del TDD è davvero inestimabile ed è difficile misurare quanto risparmi nelle ore di lavoro; anche se un modo sarebbe quello di contare le ore che hai speso in precedenza per lavorare su problemi di progettazione in fase di sviluppo. Con i test unitari è possibile esercitare un sottoinsieme del codice attraverso i test senza dover eseguire la propria applicazione o sistema. In questo modo puoi assicurarti tramite TDD che una parte del tuo programma è funzionante giusto ora , anche se potrebbe non essere collegato al cosa reale al momento.
A breve termine intendi piccoli progetti, o intendi i primi giorni di un progetto?
Sono convinto che l'integrazione dei test durante la posa dei primi lavori preliminari pagherà subito i dividendi perché hai verificato i pilastri su cui si baserà l'intero resto del progetto. Tendo a progettare dall'alto verso il basso e attuare dal basso verso l'alto, quindi questo ha senso per il mio modo di lavorare.
Se ora raccogli un incongruenza, il tuo lavoro si è ripagato da solo non dovendo eseguire il debug di un programma più complesso in seguito.
Inoltre, il tuo progetto è già configurato per i test e non dovrai effettuare il refactoring di un rig in seguito.
Un vantaggio a breve termine che trovo da TDD è che non devo concentrarmi così tanto su quello che sto cercando di ottenere.
Se vengo interrotto dal mio lavoro, senza TDD ci vogliono alcuni minuti per ricordare a me stesso dove sono quando torno all'attività.
Con TDD ho appena eseguito i test per vedere quale fallisce e immediatamente so cosa stavo cercando di ottenere. Lavoro più velocemente con meno mal di cervello.