BDD NL

My talk on BDD from Cocoaheads NL given on 15.03.2017

Transcript

1. Behavior Driven
   Development
   

   View Slide

2. View Slide

3. View Slide

4. cocoa_nl_20
   

   View Slide

5. View Slide

6. View Slide

7. View Slide

8. Behavior Driven
   Development
   8
   

   View Slide

9. What is a unit test?
   @eldudi 9
   

   View Slide

10. A method by which individual units of
    source code, sets of one or more program
    modules together with associated control
    data, usage procedures, and operating
    procedures are tested to determine if they
    are fit for use.
    --Kolawa, Adam; Huizinga, Dorota (2007)
    @eldudi 10
    

    View Slide

11. Um, what?
    @eldudi 11
    

    View Slide

12. A method by which individual units of
    source code, sets of one or more program
    modules together with associated control
    data, usage procedures, and operating
    procedures are tested to determine if they
    are fit for use.
    --Kolawa, Adam; Huizinga, Dorota (2007)
    @eldudi 12
    

    View Slide

13. What is an app?
    @eldudi 13
    

    View Slide

14. An app is a set of
    behaviors created by
    programmer and
    expected by user.
    @eldudi 14
    

    View Slide

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

    View Slide

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

    View Slide

17. This means that we
    can, by accident,
    change the behavior of
    the app.
    @eldudi 17
    

    View Slide

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

    View Slide

19. Enter unit tests.
    @eldudi 19
    

    View Slide

20. Unit test is a failsafe
    to make sure app
    behavior is preserved.
    @eldudi 20
    

    View Slide

21. Test Driven
    Development
    @eldudi 21
    

    View Slide

22. Tests drive the way you
    code
    @eldudi 22
    

    View Slide

23. Always write test first
    @eldudi 23
    

    View Slide

24. Tests influence
    architecture of your
    app
    @eldudi 24
    

    View Slide

25. Tests tell you whether
    your design became
    too complex
    @eldudi 25
    

    View Slide

26. There is no such thing
    as untestable behavior
    Only untestable code
    @eldudi 26
    

    View Slide

27. Have to simulate
    behavior of your
    dependency
    dependency
    dependency?
    @eldudi 27
    

    View Slide

28. Need to fake seven
    objects?
    @eldudi 28
    

    View Slide

29. Need to call five
    functions to simulate
    a behavior?
    @eldudi 29
    

    View Slide

30. Hard to specify clear
    requirements?
    @eldudi 30
    

    View Slide

31. Overcomplicated
    design
    @eldudi 31
    

    View Slide

32. Thinked-through
    design
    @eldudi 32
    

    View Slide

33. First consumer of your
    API
    @eldudi 33
    

    View Slide

34. There is no such thing
    as untestable behavior
    Only untestable code
    @eldudi 34
    

    View Slide

35. What is testable code?
    @eldudi 35
    

    View Slide

36. Testable code
    ==
    Good Architecture
    @eldudi 36
    

    View Slide

37. What is good
    architecture?
    @eldudi 37
    

    View Slide

38. Cohesion
    @eldudi 38
    

    View Slide

39. Coupling
    @eldudi 39
    

    View Slide

40. Good design
    A simple definition
    @eldudi 40
    

    View Slide

41. Good design
    » High cohesion
    » Low coupling
    » Easily composable
    » Context independent
    @eldudi 41
    

    View Slide

42. Good architecture - principles
    » Single responsibility
    » Few dependencies
    » Depend on interfaces, not classes (yay POP!)
    @eldudi 42
    

    View Slide

43. @eldudi 43
    

    View Slide

44. !!!
    @eldudi 44
    

    View Slide

45. http://www.martinfowler.com/
    bliki/
    DesignStaminaHypothesis.html
    @eldudi 45
    

    View Slide

46. SOLID
    @eldudi 46
    

    View Slide

47. SOLID
    Homework
    » Goruco 2009 - SOLID Object-Oriented Design - Sandi Metz
    » MCE^3 - Software Paradigms & Patterns — Did We Get It All
    Wrong? - Jon Reid
    » MCE^3 - Jorge Ortiz
    » Clean Architecture - Uncle Bob
    @eldudi 47
    

    View Slide

48. What is BDD
    @eldudi 48
    

    View Slide

49. Behavior Driven Development
    Test Driven Development
    @eldudi 49
    

    View Slide

50. What's the difference?
    @eldudi 50
    

    View Slide

51. BDD aims to improve
    certain aspect of TDD
    @eldudi 51
    

    View Slide

52. BDD tries to help you
    know what to test
    @eldudi 52
    

    View Slide

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

    View Slide

54. Think about
    ‘behaviors’
    @eldudi 54
    

    View Slide

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

    View Slide

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

    View Slide

57. You should not be testing internal
    implementation of your object
    Only its interface
    @eldudi 57
    

    View Slide

58. Work outside-in
    @eldudi 58
    

    View Slide

59. Ubiquitous language
    @eldudi 59
    

    View Slide

60. Quick & Nimble
    @eldudi 60
    

    View Slide

61. class DolphinSpec: QuickSpec {
    override func spec() {
    it("is friendly") {
    expect(Dolphin().isFriendly).to(beTruthy())
    }
    it("is smart") {
    expect(Dolphin().isSmart).to(beTruthy())
    }
    }
    }
    

    View Slide

62. describe("a dolphin") {
    describe("its click") {
    it("is loud") {
    let click = Dolphin().click()
    expect(click.isLoud).to(beTruthy())
    }
    it("has a high frequency") {
    let click = Dolphin().click()
    expect(click.hasHighFrequency).to(beTruthy())
    }
    }
    }
    

    View Slide

63. describe("a dolphin") {
    var dolphin: Dolphin!
    beforeEach { dolphin = Dolphin() }
    describe("its click") {
    var click: Click!
    beforeEach { click = dolphin.click() }
    it("is loud") {
    expect(click.isLoud).to(beTruthy())
    }
    it("has a high frequency") {
    expect(click.hasHighFrequency).to(beTruthy())
    }
    }
    }
    

    View Slide

64. describe("its click") {
    context("when the dolphin is not near anything interesting") {
    it("is only emitted once") {
    expect(dolphin!.click().count).to(equal(1))
    }
    }
    

    View Slide

65. describe("its click") {
    context("when the dolphin is near something interesting") {
    beforeEach {
    let ship = SunkenShip()
    Jamaica.dolphinCove.add(ship)
    Jamaica.dolphinCove.add(dolphin)
    }
    it("is emitted three times") {
    expect(dolphin.click().count).to(equal(3))
    }
    }
    }
    

    View Slide

66. Example
    @eldudi 66
    

    View Slide

67. BDD - recap
    » Tests influence your architecture
    » No such thing as untestable behavior
    » Think examples/behaviors, not tests
    » Don’t test implementation, work outside-in
    » Use ubiquitous language to make examples easily
    understandable
    @eldudi 67
    

    View Slide

68. Further read:
    » objc.io/issue-15
    » github.com/paweldudek/good-tdd-stuff
    Getting in touch:
    » @eldudi
    » pawel@dudek.mobi
    @eldudi 68
    

    View Slide