Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TDD: Cose che ho imparato (negli ultimi 12 anni)

TDD: Cose che ho imparato (negli ultimi 12 anni)

My talk at Codemotion Milano, 2016

Matteo Vaccari

November 27, 2016
Tweet

More Decks by Matteo Vaccari

Other Decks in Technology

Transcript

  1. TDD: COSE CHE HO IMPARATO
    Matteo Vaccari

    View full-size slide

  2. UNA SFIDA:
    2
    Scrivi un programma che produce la lista dei numeri da 0 a 1 milione
    Come lo testi?

    View full-size slide

  3. 3
    Autodidatta Team Orione Agile Coach ThoughtWorks
    Workshop
    Design Emergente
    Francesco Cirillo
    Miško Hevery
    Testable Code videos
    Kent Beck
    Freeman & Pryce
    Primo progetto XP!
    Primo coaching
    A terze parti
    The famous
    banking project
    The One
    Page Rewrite
    project
    The
    Panettone
    project
    Birthday
    Greetings Kata
    Open-Closed
    Principle Lab
    Simple Design
    in Action Lab
    2006 2012
    2001 2015

    View full-size slide

  4. DOMANDE
    ▫︎Il design emergente esiste davvero?
    ▫︎Il TDD richiede più tempo?
    ▫︎Come si fa con la UI?
    ▫︎Come si fa con il DB?
    ▫︎Mock sì, mock no?
    ▫︎Posso fidarmi di Uncle Bob?
    ▫︎Il TDD è morto?!?
    4
    Altre domande? Le tue domande?

    View full-size slide

  5. 1. COME INIZIARE
    5

    View full-size slide

  6. TEST LIST
    7
    $5 + 10CHF = $10 if rate is 2:1
    $5 * 2 = $10
    1. Esempi
    2. Del problema da
    risolvere
    Pag. 3 di
    “TDD By Example”
    di Kent Beck

    View full-size slide

  7. UNA SFIDA:
    8
    Scrivi un programma che produce la lista dei numeri da 0 a 1 milione
    Come lo testi?

    View full-size slide

  8. VARI TENTATIVI/1
    9

    View full-size slide

  9. VARI TENTATIVI/2
    10

    View full-size slide

  10. VARI TENTATIVI/3
    11

    View full-size slide

  11. GENERALIZE AND SIMPLIFY
    12

    View full-size slide

  12. LA TEST LIST DEVE:
    13
    ▫︎Contenere esempi
    ▫︎Del problema da risolvere
    ▫︎Che coprano tutte le variazioni (cioè gli scenari)
    ▫︎Senza implicare soluzioni di design
    User
    story
    Example
    (== Scenario)
    Test
    Example
    (== Scenario)
    Example
    (== Scenario)
    Test
    Test
    Child
    Test
    Child
    Test
    Child
    Test

    View full-size slide

  13. DA QUALE TEST PARTIRE?
    A. Da un test sulla UI? (outside-in)
    B. Da un test sulla logica di dominio?
    (inside-out)
    C. ?
    14

    View full-size slide

  14. 15
    TDD By Example,
    p. 133
    Which test should you pick next from the list?
    Pick a test that
    ■ will teach you something
    ■ you are confident you can implement
    “From known
    to unknown”

    View full-size slide

  15. 2. ASSI ORTOGONALI
    16

    View full-size slide

  16. How should the running of tests affect
    one another? Not at all.
    — Kent Beck, TDD By Example
    17

    View full-size slide

  17. If I had one test broken, I wanted one
    problem. If I had two tests broken, I
    wanted two problems.
    — Kent Beck, TDD By Example
    18

    View full-size slide

  18. A second implication of isolated tests is
    that you have to work, sometimes work
    hard, to break your problem into little
    orthogonal dimensions.
    — Kent Beck, TDD By Example
    19

    View full-size slide

  19. 20
    Questa gemma è
    molto ben nascosta in
    fondo a pag. 125 di
    “TDD By Example”

    View full-size slide

  20. UN ESEMPIO DI TEST NON ISOLATI
    21
    Martin Fowler, Refactoring

    View full-size slide

  21. UN ALTRO ESEMPIO DI TEST NON ISOLATI
    24
    Password-strength checker
    In order to be an acceptable password, a string must:
    * Have a length greater than 7 characters.
    * Contain at least one alphabetic character.
    * Contain at least one digit.
    Rob Myers, on the TDD mailing list

    View full-size slide

  22. 25
    Password-strength checker
    In order to be an acceptable password, a string must:
    * Have a length greater than 7 characters.
    * Contain at least one alphabetic character.
    * Contain at least one digit.
    @Test

    public void passwordTooShort() {

    assertEqual(false, isValidPassword(""));

    assertEqual(false, isValidPassword("aaa"));

    assertEqual(false, isValidPassword("aaaaaaa"));

    }


    @Test

    public void passwordIsGood() {

    assertEqual(true, isValidPassword("abcdefgh"));

    }

    View full-size slide

  23. @Test

    public void passwordTooShort() {

    assertEqual(false, isValidPassword(""));

    assertEqual(false, isValidPassword("aaa"));

    assertEqual(false, isValidPassword("aaaaaaa"));

    }


    @Test

    public void passwordIsGood() {

    assertEqual(true, isValidPassword("abcdefgh"));

    }


    @Test

    public void passwordContainsNoAlpha() {

    assertEqual(false, isValidPassword("12345678"));

    }

    26
    Password-strength checker
    In order to be an acceptable password, a string must:
    * Have a length greater than 7 characters.
    * Contain at least one alphabetic character.
    * Contain at least one digit.

    View full-size slide

  24. @Test

    public void passwordTooShort() {

    assertEqual(false, isValidPassword(""));

    assertEqual(false, isValidPassword("aaa"));

    assertEqual(false, isValidPassword("aaaaaaa"));

    }


    @Test

    public void passwordIsGood() {

    assertEqual(true, isValidPassword("abcdefgh"));

    }


    @Test

    public void passwordContainsNoAlpha() {

    assertEqual(false, isValidPassword("12345678"));

    }


    @Test

    public void passwordContainsNoDigit() {

    assertEqual(false, isValidPassword("abcdefgh"));

    }

    27
    Password-strength checker
    In order to be an acceptable password, a string must:
    * Have a length greater than 7 characters.
    * Contain at least one alphabetic character.
    * Contain at least one digit.
    Ora fallisce
    Ora sono invalidi
    per due motivi

    View full-size slide

  25. @Test

    public void passwordTooShort() {

    assertEqual(false, isValidPassword(""));

    assertEqual(false, isValidPassword("7aa"));

    assertEqual(false, isValidPassword("9aaaaaa"));

    }


    @Test

    public void passwordIsGood() {

    assertEqual(true, isValidPassword("1234abcd"));

    }


    @Test

    public void passwordContainsNoAlpha() {

    assertEqual(false, isValidPassword("12345678"));

    }


    @Test

    public void passwordContainsNoDigit() {

    assertEqual(false, isValidPassword("abcdefgh"));

    }

    28
    Password-strength checker
    In order to be an acceptable password, a string must:
    * Have a length greater than 7 characters.
    * Contain at least one alphabetic character.
    * Contain at least one digit.

    View full-size slide

  26. 29
    Password-strength checker
    In order to be an acceptable password, a string must:
    * Have a length greater than 7
    * Contain at least one alphabetic
    * Contain at least one digit.
    * Contain at least one uppercase
    * Contain at least one lowercase
    @Test

    public void passwordTooShort() {

    assertEqual(false, isValidPassword(""));

    assertEqual(false, isValidPassword("7aa"));

    assertEqual(false, isValidPassword("9aaaaaa"));

    }


    @Test

    public void passwordIsGood() {

    assertEqual(true, isValidPassword("1234abcd"));

    }


    @Test

    public void passwordContainsNoAlpha() {

    assertEqual(false, isValidPassword("12345678"));

    }


    @Test

    public void passwordContainsNoDigit() {

    assertEqual(false, isValidPassword("abcdefgh"));

    }

    Ora tutti i vecchi
    test sono da
    rivedere!
    New
    requirement!!!

    View full-size slide

  27. TWO WAYS TO DECOMPOSE A PROBLEM
    30
    Jeff Patton, http://jpattonassociates.com/dont_know_what_i_want/
    Incremental
    Iterative

    View full-size slide

  28. DECOMPOSE THE PROBLEM
    32
    Bill Wake, xp123.com/articles/slicing-functionality-alternate-paths

    View full-size slide

  29. GLI ASSI ORTOGONALI DI TETRIS
    ▫︎Movimento dei pezzi
    ▫︎Forma dei pezzi
    ▫︎Interazione dei pezzi fra di loro
    ▫︎Comandi del giocatore
    ▫︎Punteggio
    ▫︎Avanzamento di livello
    ▫︎Suoni e musica
    ▫︎High score e social
    ▫︎…
    33

    View full-size slide

  30. 3. DESIGN
    EMERGENTE
    34

    View full-size slide

  31. DUE TIPI DI PROGRAMMATORI
    35
    L’architetto Lo smanettone

    View full-size slide

  32. DUE TIPI DI PROGRAMMATORI
    36
    L’architetto Lo smanettone

    View full-size slide

  33. NON FA REFACTORING
    37
    Lo smanettone
    Ma va là che ne
    faccio fin
    troppo!

    View full-size slide

  34. FA DESIGN-DRIVEN TESTING
    38
    L’architetto
    Ho esperienza!
    So dove
    andiamo a
    parare!

    View full-size slide

  35. DESIGN-DRIVEN TESTING
    39
    Keith Braithwaite, TDD as if you Meant It

    View full-size slide

  36. ENTRAMBI FARANNO “BAD OOP”
    40
    L’architetto Lo smanettone
    http://geek-and-poke.com/geekandpoke/2014/11/8/frameworks

    View full-size slide

  37. TDD SECONDO KENT BECK:
    1. Quickly add a test.
    2. Run all tests and see the new one fail.
    3. Make a little change.
    4. Run all tests and see them all succeed.
    5. Refactor to remove duplication.
    41
    Pag. 1 di
    “TDD By Example”

    View full-size slide

  38. 42
    http://wiki.c2.com/?
    DoTheSimplestThingThatCouldPossiblyWork

    View full-size slide

  39. KENT BECK’S “FOUR RULES OF SIMPLE DESIGN”
    Code is simple enough when:
    1. It passes all the tests
    2. It clearly expresses intent
    3. It contains no duplication
    4. With the minimum number of elements
    43
    Da
    XP Explained

    View full-size slide

  40. SECONDO J.B. RAINSBERGER:
    44
    Improve
    names
    Remove
    duplication
    http://blog.thecodewhisperer.com/permalink/putting-an-age-old-battle-to-rest/

    View full-size slide

  41. STUDIARE IL SOFTWARE DESIGN È IMPORTANTE
    45

    View full-size slide

  42. E POI, A UN CERTO PUNTO, COMINCI A
    CAPIRE…
    46

    View full-size slide

  43. Che cosa faccio io in pratica?
    47

    View full-size slide

  44. CONDIVIDERE CON GLI STAKEHOLDER
    48

    View full-size slide

  45. 49
    ALLINEARSI SU UNA
    NUOVA FEATURE

    View full-size slide

  46. UN TEST PER VOLTA
    50
    User
    story
    Example
    (== Scenario)
    Test
    Example
    (== Scenario)
    Example
    (== Scenario)
    Test
    Test
    Child
    Test
    Child
    Test
    Child
    Test

    View full-size slide

  47. UN TEST PER VOLTA
    51
    :Foo
    User
    input
    :Foo
    User
    input
    :Bar
    :Foo
    User
    input
    :Bar
    :Baz
    :Foo
    User
    input
    IF
    :Foo
    User
    input
    IF
    IF
    IF

    View full-size slide

  48. ASPETTA DI TROVARE LE ASTRAZIONI BUONE
    52
    https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8

    View full-size slide

  49. 4. CHE FARE CON IL
    DB?
    53

    View full-size slide

  50. 54
    Object-Oriented DB-Oriented
    Parte dai comportamenti Parte dai dati
    Disaccoppia il DB Strettamente accoppiato al DB
    TDD è difficile
    TDD: OK!

    View full-size slide

  51. THE “SANDWICH” PATTERN
    55


    // we start the use case in the world of infrastructure

    CounterRepository repository = ...;

    Counter counter = repository.findCounter(id);


    // here we enter the world of pure logic

    counter.increment();


    // here we return to the world of infrastructure

    dao.save(counter);



    View full-size slide

  52. 56
    The database is
    just a detail that you don’t
    need to figure out right
    away.

    View full-size slide

  53. SIAMO ALLA FINE…
    57

    View full-size slide

  54. HO RISPOSTO?
    ▫︎Il design emergente esiste davvero?
    ▫︎Il TDD richiede più tempo?
    ▫︎Come si fa con la UI?
    ▫︎Come si fa con il DB?
    ▫︎Mock sì, mock no?
    ▫︎Posso fidarmi di Uncle Bob?
    ▫︎Il TDD è morto?!?
    58
    Altre domande? Le tue domande?

    View full-size slide

  55. WHERE TO FIND MORE HELP
    ▫︎Milano XPUG
    ▫︎Rileggi “TDD By Example” una volta all’anno
    ▫︎J.B. Rainsberger’s video training
    ▫︎Growing Object-Oriented Software book and mailing list
    ▫︎TDD Mailing list on Yahoo
    59

    View full-size slide

  56. PER IL PROSSIMO EVENTO TDD A MILANO…
    60
    Please subscribe!

    View full-size slide

  57. matteo.vaccari.name/blog
    twitter.com/xpmatteo
    thoughtworks.com
    GRAZIE
    Assumiamo!
    matteo.vaccari.name

    View full-size slide