Behaviour Driven Development - Mobile Trends

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

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
    pawel@dudek.mobi
    Resources
    Contact
    objc.io/issue-15
    43
    

    View Slide