BDD Mobilization

Talk from Mobilization 2015 Edition http://2015.mobilization.pl/#when-where

Transcript

1. @eldudi
   Behavior
   Driven Development
   Paweł Dudek
   

   View Slide

2. @eldudi
   

   View Slide

3. @eldudi
   

   View Slide

4. @eldudi
   Behavior
   Driven Development
   Paweł Dudek
   

   View Slide

5. @eldudi
   What is a unit test?
   5
   

   View Slide

6. @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.”
   6
   

   View Slide

7. @eldudi
   Um… what?
   7
   

   View Slide

8. @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.”
   8
   Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in
   Software Management.
   

   View Slide

9. @eldudi
   What is an app?
   9
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. @eldudi
    Enter unit tests.
    15
    

    View Slide

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

    View Slide

17. @eldudi
    They are a proof that all
    components in your app
    behave as expected
    17
    

    View Slide

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

    View Slide

19. @eldudi
    Random Project Manager
    “Who needs units tests anyway?”
    19
    

    View Slide

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

    View Slide

21. @eldudi
    No test harness
    21
    

    View Slide

22. @eldudi
    –Wikipedia
    “A safety harness is a form of protective
    equipment designed to protect a person,
    animal, or object from injury or damage.”
    22
    

    View Slide

23. @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.”
    23
    

    View Slide

24. @eldudi
    Write failing test
    24
    

    View Slide

25. @eldudi
    Make it pass
    25
    

    View Slide

26. @eldudi
    Red, Green
    26
    

    View Slide

27. @eldudi
    Red, Green, Refactor
    27
    

    View Slide

28. @eldudi
    TDD is born
    28
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

38. @eldudi
    By writing the test first,
    you're forced into thinking
    what responsibilities given
    object should have.
    38
    

    View Slide

39. @eldudi
    Let’s sidetrack a bit
    39
    

    View Slide

40. @eldudi
    What should I test?
    40
    

    View Slide

41. @eldudi
    How to explain what is
    being tested?
    41
    

    View Slide

42. @eldudi
    How to clarify
    requirements?
    42
    

    View Slide

43. @eldudi
    If you have questions
    like this - don’t worry.
    You’re not alone.
    

    View Slide

44. @eldudi
    In fact, lots of people had
    this problems. And they
    still have it.
    44
    

    View Slide

45. @eldudi
    Best TDD practitioners
    already had an answer
    45
    

    View Slide

46. @eldudi
    This is how BDD was
    created
    46
    

    View Slide

47. @eldudi
    BDD is quite simple
    47
    

    View Slide

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

    View Slide

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

    View Slide

50. @eldudi
    Think about ‘behaviours’
    50
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

54. @eldudi
    Work outside-in
    54
    

    View Slide

55. @eldudi
    Use an ubiquitous language
    that helps understand what
    are the requirements
    55
    

    View Slide

56. @eldudi
    Example
    56
    

    View Slide

57. @eldudi
    What unit tests
    can’t do?
    57
    

    View Slide

58. @eldudi
    Unit tests are never a
    guarantee that you won’t
    ship a bug.
    58
    

    View Slide

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

    View Slide

60. @eldudi
    Quick recap
    60
    

    View Slide

61. @eldudi
    BDD
    • Think examples/behaviors, not tests
    • Provide examples how your object should behave
    • Don’t test implementation, work outside-in
    • Use ubiquitous language to make examples
    easily understandable
    61
    

    View Slide

62. @eldudi
    Benefits?
    Robust codebase. Less bugs. More time for features!
    62
    

    View Slide

63. @eldudi
    Go build great stuff!
    63
    

    View Slide

64. @eldudi
    Thank you for your
    attention!
    64
    

    View Slide

65. @eldudi
    Resources & Contact
    @eldudi
    github.com/paweldudek
    pawel@dudek.mobi
    Resources
    Contact
    objc.io/issue-15
    65
    

    View Slide

66. @eldudi
    Lunch time!
    66
    

    View Slide