$30 off During Our Annual Pro Sale. View Details »

Beyond BDD

mattwynne
October 01, 2014

Beyond BDD

BDD might just be software development nirvana. But what lies beyond? What happens when a team get really, really good at BDD? Can you get so good you don't need it anymore? Let's find out.

Leading BDD expert and co-author of 'The Cucumber Book', Matt Wynne, will explore how a team evolves as they learn BDD. You’ll recognise pain-points you’ve felt yourself, discover the ones in your future, and get inspired about how far your team could get.

mattwynne

October 01, 2014
Tweet

More Decks by mattwynne

Other Decks in Programming

Transcript

  1. B E Y O N D B D D
    M A T T W Y N N E , C U K E U P ! N Y C 2 0 1 4

    View Slide

  2. View Slide

  3. S TA G E 1 :
    B U R N E D T O A S T

    View Slide

  4. S TA G E 1 : B U R N E D T O A S T
    1. Programmers write bugs
    2. Testers find bugs
    3. Project managers prioritise bugs
    4. Programmers fix bugs
    5. GOTO 1

    View Slide

  5. I ’ L L B U R N I T,
    Y O U S C R A P E I T ”
    “ L E T ’ S M A K E T O A S T T H E A M E R I C A N WAY:
    – D E M M I N G

    View Slide

  6. S TA G E 2 :
    A U T O - B U R N E D T O A S T

    View Slide

  7. S TA G E 2 : A U T O - B U R N E D T O A S T
    1. Programmers write bugs
    2. Testers write automated tests
    3. Automated tests find bugs
    4. Project managers prioritise bugs
    5. Programmers fix bugs
    6. GOTO 1

    View Slide

  8. T H AT I S
    N O T
    B D D

    View Slide

  9. E V E N I F
    Y O U ’ R E
    U S I N G
    C U C U M B E R

    View Slide

  10. C O D E T E S T F I X
    B U I L D I N G
    S O F TWA RE
    B A C K WA RD S

    View Slide

  11. B E H AV I O U R
    D R I V E N
    D E V E L O P M E N T

    View Slide

  12. C O D E T E S T F I X

    View Slide

  13. S TA G E 3 :
    T H R E E A M I G O S

    View Slide

  14. S TA G E 3 : T H R E E A M I G O S
    1. Programmers, Testers and BAs define behaviour together
    2. Programmers write (less) bugs
    3. Testers write (more) automated tests
    4. Automated tests find bugs
    5. Project managers prioritise bugs
    6. Programmers fix bugs
    7. GOTO 2

    View Slide

  15. Story
    Rule
    Example
    Question
    Question
    Rule
    Example
    Rule
    Example

    View Slide

  16. S TA G E 3 : T H R E E A M I G O S
    1. Programmers, Testers and BAs define behaviour together
    2. Programmers write (less) bugs
    3. Testers write (more) automated tests
    4. Automated tests find bugs
    5. Project managers prioritise bugs
    6. Programmers fix bugs
    7. GOTO 2

    View Slide

  17. View Slide

  18. D O T E S T E R S
    H AV E T O
    A U T O M AT E
    T H E T E S T S ?

    View Slide

  19. S TA G E 4 :
    T E S T- F I R S T

    View Slide

  20. S TA G E 4 : T E S T- F I R S T
    1. Programmers, Testers and BAs define behaviour
    together
    2. Team automate tests for that behaviour
    3. Programmers make the tests pass
    4. Testers find missing scenarios
    5. GOTO 2

    View Slide

  21. B D D

    View Slide

  22. S TA G E 5 :
    D I S I L L U S I O N M E N T

    View Slide

  23. S TA G E 5 : D I S I L L U S I O N M E N T
    • Lots of scenarios
    • Build takes ages
    • Build normally broken
    • Some scenarios flicker
    • Poor / mixed readability
    • I hate Cucumber

    View Slide

  24. VA L U E O F A T E S T O V E R T I M E
    -25
    0
    25
    50
    75
    100

    View Slide

  25. W H E N ’ S T H E
    L A S T T I M E
    Y O U P U S H E D A
    T E S T D O W N ?
    (or just deleted it altogether)

    View Slide

  26. Y O U S T I L L
    H AV E T O
    D O
    S O F T WA R E
    D E S I G N

    View Slide

  27. View Slide

  28. View Slide

  29. View Slide

  30. UI
    Unit

    View Slide

  31. UI
    Unit

    View Slide

  32. A C C E P TA N C E
    T E S T S D O N ’ T
    H AV E T O B E
    F U L L - S TA C K
    T E S T S

    View Slide

  33. S TA G E 6 :
    T R A N S C E N D E N C E

    View Slide

  34. S TA G E 6 : T R A N S C E N D E N C E
    • Problem domain is well understood by the team
    • Solution models the problem well
    • Clear architectural boundaries
    • Fewer end-to-end tests
    • Scenarios are actually readable
    • More fun

    View Slide

  35. – D AV I D W E S T, O B J E C T T H I N K I N G
    “Model the problem well enough, and the solution
    will take care of itself.”

    View Slide

  36. T H E E N D

    View Slide