Per uno, quasi mai mi siedo lì e scrivo unit test. I test unitari sono un mezzo per raggiungere un fine, non un fine in sé. Sono un modo di rispondere "questo codice fa il compito base che dovrebbe".
Ad esempio, alcune persone scriveranno una funzione, quindi apriranno una sessione interattiva per testarla su alcuni valori e assicurarsi che funzioni:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
Ma ora scopri un bug:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
Quindi lo aggiusti:
def fact x
if x < 0
raise "Can't take the factorial of a negative number"
elsif x == 0
1
else
x * fact(x-1)
end
end
>> fact -1
RuntimeError: Can't take the factorial of a negative number
from (irb):3:in `fact'
from (irb):10
Ma ora dovresti davvero testare per assicurarti che funzioni ancora:
>> fact 10
=> 3628800
>> fact 7
=> 5040
Come puoi vedere, continui a ripetere gli stessi test ... e devi confrontare i risultati visivamente. Il test unitario è un modo per evitare la ripetizione in questo caso; riduce la quantità di lavoro che devi fare. E mentre questo è un piccolo esempio sciocco, nel mondo reale, diventa sempre più importante e sempre più difficile testare manualmente. Ciò significa, ovviamente, che le persone semplicemente non testano i singoli componenti; testano semplicemente l'intero programma. Ma poi spuntano i bug e sono molto più difficili da trovare. O i bug si verificano e sono stati corretti, ma qualcuno introduce nuovamente lo stesso bug, perché nessuno ha aggiunto un caso di test per assicurarsi che ciò non accada. O qualcuno guarda un grosso pezzo di codice e dice "Non ho idea di cosa dovrebbe fare, dal momento che non è documentato e non ha test ... se correggo questo bug, non ho idea se romperò qualcos'altro a seconda di esso; forse lo riscriverò da zero. "
I test unitari riducono tutto il lavoro extra in questi casi. Il modo migliore per renderli divertenti è assicurarsi che le persone comprendano tutto il lavoro che stanno sostituendo e la flessibilità aggiuntiva che deriva dal sapere cosa dovrebbe fare ogni pezzo di codice. In una certa misura, le persone devono avere un po 'più di esperienza con la scrittura e il mantenimento di una grande base di codice per capire quanto può essere importante il test unitario; se tutto il loro codice è qualcosa che scrivono una volta e buttano via, non lo capiranno mai.
E i test unitari non dovrebbero essere scritti dopo il fatto, come ulteriore lavoretto una volta che hai il codice che "sai" già funziona. I test unitari dovrebbero essere scritti per primi, o per lo meno (poiché a volte ti dimentichi di scriverli per primi) subito dopo aver scritto il codice in questione. Questo si chiama sviluppo test-driven e può aiutare a migliorare le tue API; se scrivi i test che eseguono prima le API, imparerai dove le API sono un problema da usare prima ancora di scrivere il codice e puoi riprogettare molto più facilmente che se aggiungi solo i test in seguito.
MbUnitbiblioteca ha cambiato la mia vita. Il test automatico è importante. Il test automatico consente di risparmiare tempo. Il test automatico consente di risparmiare denaro. I test automatici possono salvare vite umane. Il test automatico è l'unico modo. L'autotest è un'altra rete di sicurezza. Quando sono una delle 50 persone che lavorano su un'architettura enorme, mi sento come l'ennesimo mattone in un muro. Con i test unitari ho il controllo.