Testare l'intestabile Per me il codice legacy è tutto quel codice che genera business ma che abbiamo paura di modificare: pochi o nessun test, forte accoppiamento, if come se piovesse... Vi è mai capitato di avere a che fare con codebase di questo genere? E magari di voler iniziare a scrivere dei test, ma questo è risultato pressoché impossibile a causa del codice stesso? Prima di pensare al "Big Rewrite", ci sono alcune tecniche che possono venirci in aiuto, permettendoci di far evolvere il nostro prodotto poco alla volta, migliorandolo senza per forza buttarlo via tutto e subito. In questo workshop useremo alcuni approcci ai test di caratterizzazione, come il Golden Master e i test di approvazione; queste tecniche consentono di ottenere una buona copertura in tempi ragionevoli, abilitando il refactoring e di conseguenza la successiva modifica ed estensione delle funzionalità.

1. TESTARE L’INTESTABILE
Ferdinando Santacroce
@jesuswasrasta #IAD19

2. Topics
•Mob Programming
•Strong-style pair programming
•Legacy code
•Characterization tests
•Bare-handed
•Golden Master
•Approval tests

3. Testing
• Vuol dire tante cose
• Unit testing, TDD, e2e, esplorativi, manuali, …
• In genere lo si intende come un modo per validare il
comportamento di un’applicazione
• Questo implica che si abbia, per iscritto o nella propria
testa, un’idea di cosa il codice faccia, una specifica
• Ma cosa fare quando non ce l’abbiamo?
(e chi può affermare di averne mai visto una esaustiva? )

4. Working with existing code
•Spesso si lavora con codice esistente
•Si deve modificare o sistemare qualcosa che
non si conosce
•Altrettanto spesso risulta difficile capire cosa
faccia il codice che osserviamo
•Ah, e quasi sempre in questi casi i test
scarseggiano...

5. The Legacy Code Dilemma
You can’t refactor code
without test coverage
You have to refactor
some code to add tests

6. Characterization tests
• Invece di spendere energie preziose nel tentare
di capire «il giro del fumo», scriviamo test di
caratterizzazione che ci permettano di delinearne
il comportamento, aiutandoci a capire cosa fa
veramente il sistema sotto test
• Scrivi un test senza fare ipotesi, eseguilo, prendi i
risultati come la verità

7. Workshop setup
•Mob programming
•Io farò Navigatore/Facilitatore
•Strong-style pair programming
•4L’s retrospective

8. Mob programming
“All the brilliant people working at the
same time, in the same space, at the
same computer, on the same thing”
Woody Zuill

9. Strong style pair programming
“For an idea to go from your head
into the computer, it MUST go
through someone else’s hands”
Llewellyn Falco

10. The Driver
Traduce linguaggio naturale in codice.
E’ una sorta di device di input intelligente.
Non può prendere iniziativa, non scrive una riga di
codice senza che gliel’abbia detto il Navigator. Può
contribuire con idee.

11. The Navigator
Programma senza toccare la tastiera.
Traduce le idee che emergono in istruzioni per il driver
* In questa speciale occasione assumerò spesso un ruolo
più direttivo, impartendo istruzioni per arrivare a mostare
alcuni passaggi

12. The Mob
E’ dove nascono le idee.
Sentitevi liberi di proporre idee e soluzioni: ne
discuteremo ed eventualmente ne testeremo l’efficacia
implementandole.

13. Timebox
•Ruotiamo ogni 20 minuti
•Ne approfittiamo per fare un piccolo break
con retrospettiva (4L’s)

14. Continuous retrospective
4L’s retrospective (notare il codice colore dei post-it)
Scriveteli mentre lavoriamo, nei break li discutiamo
Liked
Cose che ti sono piaciute
Learned
Cose che hai imparato
Lacked
Cose che abbiamo fatto, ma
che possiamo migliorare
Longed for
Desideri non soddisfatti

15. Let’s start writing the first test!
• Scrivi un test alla volta, il più piccolo che ti permetta di
scoprire qualcosa sul SUT (System Under Test)
• Non perdere tempo a pensare a un nome significativo per il
test, chiamalo «test»
• Non fare ipotesi: lascia che il codice riveli il risultato
• Sistema l'asserzione in modo che corrisponda alla realtà
• Dai al test un nome significativo