Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Testare l'intestabile - Workshop - XPUGBG

28 views

Published on

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à.

2019-09-24

@xpugbg

Published in: Software
  • Be the first to comment

  • Be the first to like this

Testare l'intestabile - Workshop - XPUGBG

  1. 1. TESTARE L’INTESTABILE Ferdinando Santacroce @jesuswasrasta @xpugbg
  2. 2. Agenda • 19:30 - 21:00 Workshop • 21:00 - ??:?? Cena presso birreria Mc Mayer’s Chi si ferma per cena? Così prenotiamo 😉
  3. 3. Topics •Mob Programming (sort of) •Strong-style pair programming •Legacy code •Characterization tests •Bare-handed •Golden Master •Approval tests
  4. 4. 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? )
  5. 5. 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...
  6. 6. The Legacy Code Dilemma You can’t refactor code without test coverage You have to refactor some code to add tests
  7. 7. 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à
  8. 8. Workshop setup •«Simil» Mob programming •Farò sempre io da Navigatore/Facilitatore •Strong-style pair programming •4L’s retrospective
  9. 9. 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
  10. 10. 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
  11. 11. 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.
  12. 12. 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
  13. 13. The Mob E’ dove nascono le idee. Sentitevi liberi di proporre idee e soluzioni: ne discuteremo ed eventualmente ne testeremo l’efficacia implementandole.
  14. 14. Timebox •Ruotiamo il Driver ogni 20 minuti •Ne approfittiamo per fare un piccolo break con retrospettiva (4L’s)
  15. 15. 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
  16. 16. 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

×