Diciamo che volevi testare manualmente la tua applicazione ogni volta che la distribuivi. Come faresti a farlo?
Bene, per cominciare, potresti fare una lista di tutte le cose che vuoi testare in modo da non dimenticare di testare qualcosa più tardi. Quindi probabilmente scriveresti i passaggi per ciascun test per assicurarti di averli eseguiti allo stesso modo ogni volta. Se non hai verificato che il processo di test che hai utilizzato fosse coerente, i tuoi risultati non sarebbero coerenti.
Quindi, ora che hai l'elenco dei test che devi eseguire, devi aprire il browser, leggere i passaggi del primo test, eseguirli e prendere nota del risultato. Ripeteresti questa procedura per ogni test nel tuo elenco.
Il numero di test che esegui continuerà a crescere man mano che la tua applicazione cresce e quando trovi nuovi bug. Ovviamente, si dovrebbe limitarsi a eseguire questi test a velocità umana, rendendoli piuttosto lenti.
L'ironia qui è che, passando da un elenco di operazioni a un altro, stai calcolando. Lo stai facendo molto più lentamente di, ad esempio, un computer.
Questo, tra molti altri buoni motivi, è il motivo per cui scriviamo test unitari: lasciano che il computer esegua il computer in modo da non doverlo fare.
Posso eseguire una suite di test unitaria completa abbastanza velocemente da usarla spesso durante lo sviluppo, non solo una volta alla settimana prima della distribuzione. Ciò mi consente di rilevare gli errori più rapidamente, risparmiando tempo e denaro.
Posso persino scrivere test che predicono il comportamento del sistema e then scrivere quel comportamento (che già so è corretto perché l'ho appena testato), un processo noto come Test Driven Development.