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

Behaviour Driven Development - the whys and hows

Behaviour Driven Development - the whys and hows

Pawel Dudek

April 20, 2015
Tweet

More Decks by Pawel Dudek

Other Decks in Programming

Transcript

  1. @eldudi
    Behavior
    Driven Development
    Paweł Dudek

    View Slide

  2. @eldudi
    What is a unit test?
    2

    View Slide

  3. @eldudi
    Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in
    Software Management.
    “Unit testing is a method by which
    individual units of source code, sets of
    one or more computer program
    modules together with associated
    control data, usage procedures, and
    operating procedures are tested to
    determine if they are fit for use.”
    3

    View Slide

  4. @eldudi
    Um… what?
    4

    View Slide

  5. @eldudi
    “Unit testing is a method by which
    individual units of source code, sets of
    one or more computer program
    modules together with associated
    control data, usage procedures, and
    operating procedures are tested to
    determine if they are fit for use.”
    5
    Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in
    Software Management.

    View Slide

  6. @eldudi
    What is an app?
    6

    View Slide

  7. @eldudi
    An app is a set of
    behaviours created by
    programmer and
    expected by user.
    7

    View Slide

  8. @eldudi
    We, programmers, have
    a limited cognition. As
    all humans do.
    8

    View Slide

  9. @eldudi
    We can’t always ‘load’
    all of the code of our
    app into our memory.
    9

    View Slide

  10. @eldudi
    This means that we can,
    by accident, change the
    behaviour of the app.
    10

    View Slide

  11. A
    11

    View Slide

  12. A B
    12

    View Slide

  13. A B
    13

    View Slide

  14. A B
    C
    14

    View Slide

  15. A B
    C
    15

    View Slide

  16. @eldudi
    Preserving behaviour of
    complex systems is
    hard. In fact, of any
    system at all.
    16

    View Slide

  17. @eldudi
    Enter unit tests.
    17

    View Slide

  18. @eldudi
    Unit test is a failsafe to
    make sure app
    behaviour is preserved.
    18

    View Slide

  19. @eldudi
    They are a proof that all
    components if your app
    behave as expected
    19

    View Slide

  20. @eldudi
    Sounds like tests are a
    godsend, doesn’t it?
    20

    View Slide

  21. @eldudi
    What is a usual approach
    to testing?
    21

    View Slide

  22. @eldudi
    Random Project Manager
    “Lets just write tests afterwards.”
    22

    View Slide

  23. @eldudi
    No test harness
    23

    View Slide

  24. @eldudi
    Providing a proof whether
    program works after it has
    been written increases
    burden on the programmer
    24

    View Slide

  25. @eldudi
    “Programmer should let the correctness
    proof and program grow in hand.”
    –Edsger W. Dijkstra
    25

    View Slide

  26. @eldudi
    –Edsger W. Dijkstra
    “If one first asks oneself what the structure
    of a convincing proof would be and, having
    found this, then constructs a program
    satisfying this proof’s requirements, then
    these correctness concerns turn out to be
    a very effective heuristic guidance.”
    26

    View Slide

  27. @eldudi
    Write failing test
    27

    View Slide

  28. @eldudi
    Make it pass
    28

    View Slide

  29. @eldudi
    Red, Green
    29

    View Slide

  30. @eldudi
    Red, Green, Refactor
    30

    View Slide

  31. @eldudi
    TDD is born
    31

    View Slide

  32. @eldudi
    In TDD you always
    write test first. Always.
    32

    View Slide

  33. @eldudi
    Which is then made
    green by
    writing/refactoring code
    33

    View Slide

  34. @eldudi
    TDD is not “just adding
    tests first”. It’s a complete
    workflow.
    34

    View Slide

  35. @eldudi
    TDD is a great way to
    determine how complex your
    code has become.
    You just have to listen.
    35

    View Slide

  36. @eldudi
    Have to fake seven
    objects to isolate test?
    36

    View Slide

  37. @eldudi
    Have to inject a fake
    into a fake into a fake?
    37

    View Slide

  38. @eldudi
    Your test setup
    method has 70 lines?
    38

    View Slide

  39. @eldudi
    This always points to an
    overcomplicated design
    And your tests are here to point
    that out. Very clearly
    39

    View Slide

  40. @eldudi
    By writing test first you’re
    becoming a consumer of
    your upcoming API
    40

    View Slide

  41. Is that API hard to test?
    41

    View Slide

  42. That means it will probably
    be hard to consume too.
    42

    View Slide

  43. Or it will be really hard to
    maintain.
    43

    View Slide

  44. @eldudi
    But TDD didn’t really
    answer all the questions
    44

    View Slide

  45. @eldudi
    What should I test?
    45

    View Slide

  46. @eldudi
    How to explain what
    given test is testing?
    46

    View Slide

  47. @eldudi
    How to clarify
    requirements?
    47

    View Slide

  48. @eldudi
    How to provide
    examples?
    48

    View Slide

  49. @eldudi
    This is where BDD
    enters the stage
    49

    View Slide

  50. @eldudi
    BDD is quite simple
    50

    View Slide

  51. @eldudi
    But it requires a shift in
    how you perceive your test
    suite
    51

    View Slide

  52. @eldudi
    When writing tests don’t
    think ‘tests’
    52

    View Slide

  53. @eldudi
    Think about ‘behaviours’
    53

    View Slide

  54. @eldudi
    Think about examples how
    your object should behave
    54

    View Slide

  55. @eldudi
    An objects behaviour is
    defined by methods it
    declares in its interface
    55

    View Slide

  56. @eldudi
    You should not be testing
    internal implementation of
    your object
    56

    View Slide

  57. @eldudi
    BDD provides an ubiquitous
    language that helps
    understand what are the
    requirements
    57

    View Slide

  58. @eldudi
    Example
    58

    View Slide

  59. @eldudi
    Tools
    59

    View Slide

  60. @eldudi
    Specta
    60

    View Slide

  61. @eldudi
    Expecta
    61

    View Slide

  62. @eldudi
    OCMockito
    62

    View Slide

  63. @eldudi
    Let’s do it!
    63

    View Slide

  64. What unit tests
    can’t do?
    64

    View Slide

  65. Unit tests are never a
    guarantee that you
    won’t ship a bug.
    65

    View Slide

  66. But they’re damn good at
    greatly reducing amount
    of bugs. And time spent
    on QA.
    66

    View Slide

  67. Are unit tests an invaluable tool for
    writing great software? Heck yes.
    Am I going to produce a poor product
    if I can’t unit test? Hell no.
    Jonathan Rasmusson
    67
    http://agilewarrior.wordpress.com/2012/10/06/its-not-about-the-unit-tests/

    View Slide

  68. @eldudi
    Thank you for your
    attention!
    68

    View Slide

  69. @eldudi
    Resources & Contact
    @eldudi
    github.com/paweldudek
    [email protected]
    Resources
    Contact
    objc.io/issue-15

    View Slide