Appena un programmatore novizio sente parlare di "test", si rende subito conto che sta per imbarcarsi in una faccenda oscura: ore sprecate nel cercare ogni piccolo baco, creazioni di funzioni inutili che non verranno mai utilizzate dal programma stesso, tempo che poteva essere utilizzato nello sviluppo di nuovi features del software. Il programmatore non riuscirà mai a lavorare a queste cose in maniera felice e producente, ritenendole solamente una interruzione nello sviluppo dell'applicazione. Questa è ovviamente la maniera sbagliata di intraprendere l'attività di testing.
La maniera più semplice, e logica, di scrivere test è scrivere i test prima del codice applicazione. Questo è l'elemento fondamentale del TDD (test-driven development); ci permette di sviluppare la struttura del programma durante la programmazione che, con un minimo di design iniziale, si intravede crescere tramite la scrittura dei test.
Supponiamo di creare un'applicazione per calcolare il punteggio di una partita di bowling. Potremmo cominciare a strutturare l'applicazione cercando di capire ogni singolo dettaglio del problema, e di risolverlo, prima ancora di scrivere codice. Oppure possiamo partire dagli elementi più semplici del problema, in questo caso, le azioni svolte durante una partita di bowling.
/* lancia la palla 20 volte, e prendi 0 birilli ogni volta */
for(int i=0; i < 20; i++) {
partita_bowling_roll(0);
}
Oltre ad avere una struttura solida con cui iniziare, abbiamo anche scritto il nostro primo test, quindi per qualsiasi cambiamento dell'implementazione saremmo sempre certi del successo dei nostri test. Questo diventa un dato importantissimo una volta che le dimensioni del software cominciano a crescere.
La tecnica del TDD è sinonimo dell'igene della nostra applicazione. Nello stesso modo in cui i dottori si lavano le mani prima di operare, noi dobbiamo scrivere test prima del codice applicazione.