Il ritmo del Test-Driven Development (live coding) #AVV2020
Applicare TDD con ritmo è frutto di tanto esercizio.
Durante questa live session tenuta all’Agile Venture Vimercate 2020 Andrea Francia ci ha dimostrato l’efficacia del Test-Driven Development, o più comunemente TDD, attraverso un kata.
Un code kata è un esercizio di programmazione che aiuta i programmatori ad affinare le loro abilità attraverso la pratica e la ripetizione.
Andrea ci tiene a sottolineare che il TDD (1) è una tecnica di sviluppo software, non di test. E’ composta da tre fasi, che definiscono se vogliamo un ritmo:
- RED
- Aggiungi velocemente un test.
- Esegui tutti i test. L’ultimo fallisce.
- GREEN
- Fai una modifica, che sia piccola e quindi semplice.
- Esegui tutti i test e vedili passare tutti.
- REFACTOR
- Fai refactor al codice fino a togliere tutta la duplicazione.
Questa la teoria, ma in pratica…
- Aggiungi un test.
- Esegui tutti i test e li vedi fallire.
- Fai una modifica.
- Ti accorgi che non basta.
- Modifichi altre classi esistenti.
- Esegui i test, e ti accorgi che falliscono. Sia i vecchi che i nuovi.
- Prendi “a martellate” il codice.
- Tutti i test passano.
Come evitare tutto ciò? Riconsiderando bene il ritmo del TDD, ovvero aggiungere velocemente un test, e fare una piccola modifica. Non sempre la modifica è piccola, in questo caso il consiglio è di “tornare indietro”, rifattorizzare il codice per “preparare il campo” e quindi applicare la piccola modifica.
Tornando al kata, l’obiettivo è sviluppare un delivery service che, data la dimensione di un pacco, deve restituire l’elenco di tutti i punti di ritiro disponibili (hub o locker). Per chi volesse approfondire la soluzione dell’esercizio, il codice è disponibile sulla pagina GitHub di Andrea (2)
Tra un test, una modifica, un’esecuzione e un commit Andrea ha fatto emergere dei consigli sul Test-Driven Development:
- Prepararsi in un file a parte una lista di test che si vogliono fare, e tenerla aggiornata.
- Il refactor si può fare sempre, quando tutti i test sono verdi, o comunque “prima del rosso” cioè quando un test fallisce.
- Quando ci accorgiamo che un codice non è completamente testato (magari delle variabili non usate), aggiungere un test in più e quindi ovviare al problema.
- Nella situazione in cui un test richiede tante modifiche, piuttosto commentiamo quel test, committiamo dopodiché proseguiamo facendo refactor perché appunto ho tutti i test verdi (ho commentato il test che falliva). Refactor propedeudico per poi poter effettuare una modifica piccola.