Che cosa è Test-Driven Development (TDD)?

large__8282043567 Lo sviluppo basato su test è un processo che si basa sulla ripetizione di un ciclo di sviluppo molto breve. Si basa sul concetto test-first di Extreme Programming (XP) che incoraggia il design semplice con un alto livello di fiducia.

La procedura di fare TDD sta seguendo:

  1. Scrivi un test
  2. Esegui tutti i test
  3. Scrivi il codice di implementazione
  4. Esegui tutti i test
  5. Refactor

Questa procedura è spesso chiamata Red-Green-Refactor.

Mentre scriviamo i test siamo nello stato rosso. Poiché il test è scritto prima dell’effettiva implementazione, si suppone che fallisca. Se non lo fa, il test è sbagliato. Descrive qualcosa che esiste già o è stato scritto in modo errato. Essere in verde durante la scrittura di test è un segno di falso positivo. Test del genere dovrebbero essere rimossi o refactored.

Segue lo stato verde. Quando l’implementazione dell’ultimo test è terminata, tutti i test dovrebbero passare. Se non lo fanno, l’implementazione è sbagliata e dovrebbe essere corretta.

L’idea non è di rendere l’implementazione finale, ma di fornire un codice sufficiente per il passaggio dei test. Una volta che tutto è verde possiamo procedere al refactoring del codice esistente. Ciò significa che stiamo rendendo il codice più ottimale senza introdurre nuove funzionalità. Mentre il refactoring è in atto, tutti i test dovrebbero passare tutto il tempo. Se uno di questi fallisce, refactor ha rotto una funzionalità esistente. Il refactoring non dovrebbe includere nuovi test.

La velocità è la chiave

large_5836417589
Tendo a vedere TDD come un gioco di ping pong (o ping pong). Il gioco è molto veloce. Lo stesso vale per TDD. Tendo a non spendere più di un minuto su entrambi i lati del tavolo (test e implementazione). Scrivi un breve test ed eseguilo (ping), scrivi l’implementazione ed esegui tutti i test (pong), scrivi un altro test (ping), scrivi l’implementazione di quel test (pong), refactoring e conferma che tutti i test stanno passando (punteggio), ripeti. Ping, pong, ping, pong, ping, pong, punteggio, servire di nuovo. Non cercare di creare il codice perfetto. Invece, cercare di mantenere la palla a rotazione fino a quando si pensa che il tempo è giusto per segnare (refactoring).

Non si tratta di testare

T in TDD è spesso frainteso. TDD è il modo in cui ci avviciniamo al design. È il modo per costringerci a pensare all’implementazione prima di scrivere il codice. È il modo per strutturare meglio il codice. Ciò non significa che i test derivanti dall’utilizzo di TDD siano inutili. Tutt’altro. Sono molto utili e ci permettono di sviluppare con grande velocità senza temere che qualcosa si rompa. Ciò è particolarmente vero quando avviene il refactoring. Essere in grado di riorganizzare il codice pur avendo la certezza che nessuna funzionalità è interrotta è un enorme aumento della qualità del codice.

L’obiettivo principale di TDD è la progettazione del codice con test come prodotto laterale molto utile.

Beffardo

Affinché i test possano essere eseguiti velocemente fornendo un feedback costante, il codice deve essere organizzato in modo che metodi, funzioni e classi possano essere facilmente derisi e stoppati. La velocità dell’esecuzione sarà gravemente compromessa, ad esempio, i nostri test devono comunicare con il database. Prendendo in giro le dipendenze esterne siamo in grado di aumentare drasticamente quella velocità. L’intera esecuzione della suite di test unitari deve essere misurata in minuti se non secondi. Ancora più importante della velocità, progettare il codice in modo che possa essere facilmente deriso e stoppato ci costringe a strutturare meglio quel codice applicando la separazione delle preoccupazioni. Con o senza mock, il codice dovrebbe essere scritto in un modo che possiamo, ad esempio, sostituire facilmente un database con un altro. Quel” altro ” può essere, ad esempio, deriso o database in memoria.

Un esempio di mocking in Scala può essere trovato in Scala Test-Driven Development (TDD): Unit Testing File Operations with Specs2 and Mockito article. Se il tuo linguaggio di programmazione preferito non è Scala, l’articolo può ancora essere molto utile per vedere il modello che può essere applicato a qualsiasi lingua.

Osservatori

Strumento molto utile quando si lavora nella moda TDD sono osservatori. Sono framework o strumenti che vengono eseguiti prima di iniziare a lavorare e stanno osservando qualsiasi modifica nel codice. Quando viene rilevata una tale modifica, vengono eseguiti tutti i test. In caso di JavaScript, quasi tutti i sistemi di compilazione e i task runners lo consentono. Gulp (il mio preferito) e Grunt sono due dei molti esempi. Scala ha sbt-revolver (tra gli altri). La maggior parte degli altri linguaggi di programmazione ha strumenti simili che ricompilano (se necessario) ed eseguono tutti i test (o interessati) quando il codice cambia. Finisco sempre per avere il mio schermo diviso in due finestre. Uno con il codice su cui sto lavorando e l’altro con i risultati dei test che vengono eseguiti continuamente. Tutto quello che devo fare è prestare attenzione che l’output di quegli osservatori corrisponda alla fase in cui mi trovo (rosso o verde).

Documentazione

Un altro effetto collaterale molto utile di TDD (e test ben strutturati in generale) è la documentazione. Nella maggior parte dei casi, è molto più facile scoprire cosa fa il codice guardando i test rispetto all’implementazione stessa. Un ulteriore vantaggio che altri tipi di documentazione non possono fornire è che i test non sono mai obsoleti. Se c’è qualche discrepanza tra i test e il codice di implementazione, i test falliscono. Test falliti significano documentazione imprecisa.

Test come articolo di documentazione fornisce un ragionamento un po ‘ più profondo dietro l’uso di test invece della documentazione tradizionale.

Sommario

Nella mia esperienza, TDD è probabilmente lo strumento più importante che abbiamo nel nostro toolbox software. Ci vuole un sacco di tempo e pazienza per diventare abili in TDD, ma una volta che l’arte è padroneggiata, la produttività e la qualità aumenta drasticamente. Il modo migliore per imparare e praticare TDD è in combinazione con la programmazione a coppie. Come in un gioco di ping pong che richiede due partecipanti, TDD può essere a coppie in cui un coder scrive test e l’altro scrive l’implementazione di tali test. I ruoli possono cambiare dopo ogni test (come spesso avviene nei dojo di codifica).

Fai un tentativo e non arrenderti di fronte agli ostacoli poiché ce ne saranno molti.

Test Driven Development (TDD): le best practice che utilizzano esempi Java sono un buon punto di partenza. Anche se utilizza esempi Java, le stesse pratiche, se non tutte, possono essere applicate a qualsiasi linguaggio di programmazione. Per un esempio in Java (come nel caso precedente, è facilmente applicabile ad altre lingue) si prega di dare un’occhiata a TDD Esempio articolo Walkthrough.

Un altro ottimo modo per perfezionare le abilità TDD sono i code kata (ce ne sono molti su questo sito).

Qual è la tua esperienza con TDD? Ci sono tante varianti quante sono le squadre che lo praticano e mi piacerebbe conoscere la tua esperienza.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.