Best practice per i test unitari per un neofita del test unitario

Negli ultimi anni, ho scritto solo piccoli componenti per le persone in progetti più grandi o piccoli strumenti. Non ho mai scritto un test unitario e sembra sempre come imparare a scriverli e realizzarne uno richiede molto più tempo che semplicemente accendere il programma e testarlo davvero.

Sto per iniziare un progetto su larga scala che potrebbe richiedere alcuni mesi per essere completato e mentre cercherò di testare gli elementi mentre li scrivo (come sempre), mi chiedo se i test unitari potrebbero farmi risparmiare tempo.

Mi chiedevo solo se qualcuno potesse dare un buon consiglio:

1. Dovrei guardare i test unitari all'inizio del progetto e possibilmente adottare un approccio TDD.
2. Devo solo scrivere test mentre procedo, dopo che ogni sezione è completa.
3. Devo completare il progetto e quindi scrivere i test unitari alla fine.

Alcuni diranno il contrario, ma suggerirei di separare TDD e Unit Testing. TDD è piuttosto un cambiamento mentale e inizialmente i test unitari richiedono tempo. Se li consideri come un elemento, c'è il rischio che non vedrai subito abbastanza benefici e ci sarà la tentazione di abbandonare semplicemente TDD e Test unitari con esso.

La prima cosa è scrivere alcuni test unitari. All'inizio non devono essere perfetti. Basta insegnare a te stesso come testare piccole unità di codice e come usare il derisione per isolare i componenti.

Questo è il più grande che richiede tempo ma ha di gran lunga il più grande profitto. Una volta notato che non è più necessario sfogliare 14 pagine Web per arrivare a quella che si desidera verificare, saprai di cosa sto parlando.

Per me, il grande momento di Eureka è stato un'app di Windows in cui stavo cercando di provare una regex che mi ha richiesto di compilare due moduli prima di poterlo accedere. Ho installato NUnit e ho scritto un test su quel metodo e ho visto quanto velocemente ho risparmiato ore di tempo di test. Quindi ho aggiunto altri test per gestire i casi limite. E così via.

Quindi impara a scrivere bene i test unitari. Impara l'equilibrio tra i test fragili che sono veloci da scrivere e scrivere molti molti test individuali. Questo è abbastanza facile. La lezione è che idealmente ogni test mette alla prova solo una cosa, ma impari rapidamente quanto tempo ci vuole, quindi inizi a piegarti un po 'sulla regola fino a scrivere un test che si interrompe su ogni modifica del codice, quindi torni indietro al giusto equilibrio (che è più vicino al primo rispetto al secondo).

TDD è, come ho già detto, un grande cambiamento mentale nel modo in cui lavori. Tuttavia, non ci vorrà molto tempo per il processo di sviluppo dopo aver già scritto i test. E, lo prometto, vedrai migliorare il tuo stile di codifica sotto i tuoi occhi. O meglio, se non lo lasci cadere, non fa per te.

Un'ultima cosa da tenere a mente è che il TDD non si limita ai test unitari. Il design guidato dai test di accettazione fa parte del TDD. Un altro buon motivo per non confonderli nella tua mente.

Sono d'accordo con gli altri (sicuramente non scrivere i tuoi test alla fine, TDD richiede tempo per imparare, iniziare con i test comunque puoi, puntare a un TDD completo alla fine). Ma volevo aggiungere una cosa in risposta al tuo commento: "Mi chiedo se i test unitari potrebbero farmi risparmiare tempo".

La mia risposta è un sì inequivocabile. Ho imparato l'approccio TDD circa 10 anni fa, dopo un periodo simile di programmazione senza test. In questi giorni, se sto facendo qualcosa di breve (<250 loc) e semplice, o qualcosa da buttare, allora non lo farò. Altrimenti, lo faccio, e proprio perché fa risparmiare tempo.

Il risparmio di tempo è disponibile in tre modi: meno WTF, meno debug e meno paura. Il primo è ovvio: passi molto meno tempo a chiederti cosa diavolo sta facendo la cosa che hai costruito. Quando si riscontra un problema, il debug è molto più semplice, poiché a) si rilevano istantaneamente i bug testati e b) i bug non testati hanno meno posti da nascondere.

La cosa meno paura, però, è più sottile. Fino a quando non hai trascorso un po 'di tempo in una base di codice TDD, non ti rendi nemmeno conto di quanto tempo ti preoccupi per le modifiche che stai apportando. X funziona? Si romperà Y? C'è qualche Z che potrebbe essere influenzata? Con TDD, questo scompare, perché trasformi le tue paure in prove, e quindi il computer automatizza le preoccupazioni. Uno sviluppatore più coraggioso è uno sviluppatore più veloce.

1. Dovrei guardare l'unità all'inizio e adottare un approccio TDD.

2. Devo solo scrivere test mentre procedo dopo che ogni sezione è stata completata.

Ognuna di queste, ma non la terza opzione .

Come notato da @pdr, l'apprendimento di test di unità adeguati richiede tempo. Vuoi sicuramente prenderti il ​​tempo per imparare all'inizio del ciclo di vita del progetto, non verso la fine quando la scadenza si profila sulla tua testa. In questo modo sei già al passo con i tempi e potresti persino iniziare a raccogliere i frutti quando la scadenza si avvicina, a causa della maggior parte dei bug rilevati durante il ciclo di vita del progetto.

Nota che il primo test unitario è sempre il più difficile, specialmente se stai testando un codice già scritto. Tale codice potrebbe non essere compatibile con il test unitario, quindi potresti avere difficoltà a cablare tutti gli oggetti con lo stato corretto per il test. Scegli quindi un test di livello basso, abbastanza isolato, abbastanza semplice per i tuoi primi tentativi di test dell'unità, quindi gradualmente potresti aumentare il livello di sfida. Una volta che hai pronto il primo dispositivo di prova, il prossimo caso di test è molto più semplice e, quando arrivi al quarto, producerai casi di test come su un nastro trasportatore. Questo è quando si inizia a sentire la bontà di poter ripetibile, palesemente dimostrano che le tue opere di codice ...

Personalmente preferisco l'approccio TDD e non penso che sia così impegnativo - ci vuole perseveranza, ma credo che prima inizi con TDD, prima inizi a vedere i benefici del test unitario in generale. Tuttavia, è possibile che i primi test unitari siano meglio scrivere per il codice che già possiedi. Quindi, una volta capito, puoi iniziare a sperimentare TDD.

Penso che la cosa migliore da fare per un principiante sia affrontare alcuni kata di codice che si prestano ai test unitari. Per esempio; convalida di un indirizzo e-mail. TDD diventa il flusso naturale dopo aver affrontato alcuni di questi Code Katas. Controlla il seguente codice kata per il validatore dell'indirizzo e-mail che ho menzionato: Convalida e-mail

Per una spiegazione di cosa sono i Code Katas per quelli di voi che non lo sanno, controllate il seguente link: Code Katas