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

Behaviour Driven Development - Mobile Trends

Pawel Dudek
February 19, 2016

Behaviour Driven Development - Mobile Trends

Slides from presentation given at [Mobile Trends](http://www.2016.mobiletrends.pl)

Pawel Dudek

February 19, 2016
Tweet

More Decks by Pawel Dudek

Other Decks in Programming

Transcript

  1. @eldudi
    Behavior
    Driven Development
    Paweł Dudek

    View Slide

  2. View Slide

  3. @eldudi
    Behavior
    Driven Development
    Paweł Dudek

    View Slide

  4. @eldudi
    What is a unit test?
    4

    View Slide

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

    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. @eldudi
    Preserving behaviour of
    complex systems is
    hard. In fact, of any
    system at all.
    11

    View Slide

  12. @eldudi
    Enter unit tests.
    12

    View Slide

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

    View Slide

  14. @eldudi
    TDD
    14

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. @eldudi
    You need to simulate five
    events to test one
    method?
    22

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  26. @eldudi
    SOLID
    26

    View Slide

  27. @eldudi
    BDD
    27

    View Slide

  28. @eldudi
    What should I test?
    28

    View Slide

  29. @eldudi
    If you asked this
    question - don’t worry.
    You’re not alone.

    View Slide

  30. @eldudi
    BDD is quite simple
    30

    View Slide

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

    View Slide

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

    View Slide

  33. @eldudi
    Think about ‘behaviors’
    33

    View Slide

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

    View Slide

  35. @eldudi
    An objects behavior is
    defined by methods it
    declares in its interface
    35

    View Slide

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

    View Slide

  37. @eldudi
    Work outside-in
    37

    View Slide

  38. @eldudi
    Use examples to clarify
    requirements
    38

    View Slide

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

    View Slide

  40. @eldudi
    Example
    40

    View Slide

  41. @eldudi
    Recap
    41

    View Slide

  42. @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
    42

    View Slide

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

    View Slide