Test delle unità migliori pratiche per un principiante di test delle unità

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

La prima cosa è scrivere alcuni Test unitari. All'inizio non devono essere perfetti. Insegnati come testare piccole unità di codice e come usare il mocking per isolare i componenti.

Questo è il più grande time-taker ma ha di gran lunga il più grande successo. Una volta che ti accorgi che non devi più sfogliare 14 pagine web per arrivare a quello che vuoi testare, saprai di cosa sto parlando.

Per me, il grande momento Eureka era un'app per Windows in cui cercavo di testare una regex che richiedeva di compilare due moduli prima che potessi arrivarci. Ho installato NUnit e ho scritto un test su questo metodo e ho visto con quanta rapidità ho risparmiato ore di tempo di test. Poi ho aggiunto altri test per affrontare i casi limite. E così via.

Quindi impara a scrivere bene i test unitari. Scopri l'equilibrio tra i test fragili che sono veloci da scrivere e scrivere molti test individuali. Questo è abbastanza facile. La lezione è che idealmente ogni test mette alla prova solo una cosa, ma impari velocemente quanto tempo ci vuole, quindi inizi a piegarti un po 'alla regola finché non scrivi un test che rompe ad ogni cambio di codice, poi torni indietro verso il giusto equilibrio (che è più vicino al primo rispetto al secondo).

Il TDD è, come ho detto, un importante cambiamento mentale nel modo in cui lavori. Tuttavia, non aggiungerà molto tempo al tuo processo di sviluppo una volta che hai già scritto i test. E lo farai, lo prometto, vedere il tuo stile di codifica migliorare sotto i tuoi occhi. O meglio, se non lo fai cadere, non fa per te.

Un'ultima cosa da tenere a mente è che TDD non è limitato ai test unitari. Il design guidato dal test di accettazione è parte integrante del TDD. Un altro buon motivo per non confonderli nella tua mente.

Sono d'accordo con gli altri (sicuramente non scrivo i tuoi test alla fine, TDD richiede tempo per imparare, inizia con i test comunque puoi, mirare alla fine a TDD completo). Ma volevo aggiungere una cosa in risposta al tuo commento: "Mi chiedo se il test dell'unità potrebbe farmi risparmiare tempo."

La mia risposta è un sì inequivocabile. Ho imparato l'approccio TDD circa 10 anni fa, dopo una quantità di tempo simile che codificava senza test. In questi giorni, se sto facendo qualcosa di breve (< 250 loc) e semplice, o qualcosa da buttar via, allora non lo farò. Altrimenti, lo faccio, e precisamente perché risparmia tempo.

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

Meno la paura, tuttavia, è più sottile. Finché non hai passato un po 'di tempo in una base di codice TDD, non ti rendi neanche conto di quanto tempo passi a preoccuparti dei cambiamenti che stai facendo. X funziona? Si romperà Y? C'è qualche Z che potrebbe essere interessato? Con TDD, questo va via, perché trasformi le tue paure in test, e poi il computer automatizza il preoccupante. Uno sviluppatore più coraggioso è uno sviluppatore più veloce.

1. Should I be looking at unit at the start and adopt a TDD approach.

2. Should I just write tests as I go along after each section is complete.

Ciascuno di questi, ma non la terza opzione .

Come notato da @pdr, l'apprendimento dei test delle unità richiede tempo. Sicuramente vorresti del 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à in grado di accelerare e potresti persino iniziare a sfruttare i vantaggi nel momento in cui la scadenza si avvicina, poiché ha catturato la maggior parte degli errori prima del ciclo di vita del progetto.

Si noti che il primo test di unità è sempre il più difficile, soprattutto se si sta testando il codice già scritto. Tale codice potrebbe non essere unit test friendly, quindi potrebbe essere difficile collegare tutti gli oggetti con lo stato adeguato per il test. Scegli quindi un test di livello basso facile, abbastanza isolato, per i tuoi primi tentativi di test unitario, quindi gradualmente potresti aumentare il livello di difficoltà. Una volta pronto il primo dispositivo di prova, il prossimo test è molto più semplice e, quando arriverete al quarto, produrrete casi di test come su un nastro trasportatore. Questo è quando inizi a sentire la bontà di essere in grado di replicare, dimostrando in modo dimostrabile che il tuo codice funziona ...

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

Penso che la cosa migliore da fare per un principiante sia affrontare alcuni kata di codice che si prestano al collaudo di unità. Per esempio; convalida di un indirizzo e-mail. Il TDD diventa il flusso naturale una volta che hai affrontato alcuni di questi Code Katas. Controlla il seguente codice kata per il validatore degli indirizzi e-mail che ho menzionato: Validatore e-mail

Per una spiegazione di cosa sono i Code Katas per quelli che non conoscono, controlla il seguente link: Code Katas