Supponiamo che tu abbia voluto testare manualmente l'applicazione ogni volta che l'hai distribuita. Come lo faresti?
Bene, per cominciare, potresti fare un elenco di tutte le cose che vuoi testare in modo da non dimenticare di provare qualcosa in seguito. Quindi probabilmente scriveresti i passaggi per ogni test per assicurarti di averli fatti allo stesso modo ogni volta. Se non ti assicurassi che il processo di test che hai usato fosse coerente, i tuoi risultati non sarebbero coerenti.
Quindi, ora che hai l'elenco dei test che devi eseguire, dovresti aprire il browser, leggere i passaggi del primo test, eseguirli e prendere nota del risultato. Ripetere questo processo per ciascun test nell'elenco.
Il numero di test eseguiti continuerà a crescere man mano che la tua applicazione cresce e quando trovi nuovi bug. Ovviamente, ti limiteresti a eseguire questi test a velocità umana, rendendoli piuttosto lenti.
L'ironia qui è che, sfogliando meccanicamente un elenco di operazioni, stai elaborando. Lo stai facendo molto più lentamente di, diciamo, un computer.
Questo, tra le molte altre buone ragioni, è il motivo per cui scriviamo test unitari: lasciano che il computer faccia il calcolo in modo da non doverlo fare.
Posso eseguire una suite di unit test completa abbastanza velocemente da usarla frequentemente durante lo sviluppo, non solo una volta alla settimana prima della distribuzione. Questo mi consente di rilevare gli errori più rapidamente, risparmiando tempo e denaro.
Posso anche scrivere test che predicono il comportamento del sistema e quindi scrivere quel comportamento (che già conosco sia corretto perché l'ho appena testato), un processo noto come Test Driven Development.