BDD NL

BDD NL

My talk on BDD from Cocoaheads NL given on 15.03.2017

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

March 16, 2017
Tweet

Transcript

  1. Behavior Driven Development

  2. None
  3. None
  4. cocoa_nl_20

  5. None
  6. None
  7. None
  8. Behavior Driven Development 8

  9. What is a unit test? @eldudi 9

  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
  11. Um, what? @eldudi 11

  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
  13. What is an app? @eldudi 13

  14. An app is a set of behaviors created by programmer

    and expected by user. @eldudi 14
  15. We, programmers, have a limited cognition. As all humans do.

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

    app into our memory. @eldudi 16
  17. This means that we can, by accident, change the behavior

    of the app. @eldudi 17
  18. Preserving behavior of complex systems is hard. In fact, of

    any system at all. @eldudi 18
  19. Enter unit tests. @eldudi 19

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

    is preserved. @eldudi 20
  21. Test Driven Development @eldudi 21

  22. Tests drive the way you code @eldudi 22

  23. Always write test first @eldudi 23

  24. Tests influence architecture of your app @eldudi 24

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

    25
  26. There is no such thing as untestable behavior Only untestable

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

    27
  28. Need to fake seven objects? @eldudi 28

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

    29
  30. Hard to specify clear requirements? @eldudi 30

  31. Overcomplicated design @eldudi 31

  32. Thinked-through design @eldudi 32

  33. First consumer of your API @eldudi 33

  34. There is no such thing as untestable behavior Only untestable

    code @eldudi 34
  35. What is testable code? @eldudi 35

  36. Testable code == Good Architecture @eldudi 36

  37. What is good architecture? @eldudi 37

  38. Cohesion @eldudi 38

  39. Coupling @eldudi 39

  40. Good design A simple definition @eldudi 40

  41. Good design » High cohesion » Low coupling » Easily

    composable » Context independent @eldudi 41
  42. Good architecture - principles » Single responsibility » Few dependencies

    » Depend on interfaces, not classes (yay POP!) @eldudi 42
  43. @eldudi 43

  44. !!! @eldudi 44

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

  46. SOLID @eldudi 46

  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
  48. What is BDD @eldudi 48

  49. Behavior Driven Development Test Driven Development @eldudi 49

  50. What's the difference? @eldudi 50

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

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

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

  54. Think about ‘behaviors’ @eldudi 54

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

  56. An objects behavior is defined by methods it declares in

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

    Only its interface @eldudi 57
  58. Work outside-in @eldudi 58

  59. Ubiquitous language @eldudi 59

  60. Quick & Nimble @eldudi 60

  61. class DolphinSpec: QuickSpec { override func spec() { it("is friendly")

    { expect(Dolphin().isFriendly).to(beTruthy()) } it("is smart") { expect(Dolphin().isSmart).to(beTruthy()) } } }
  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()) } } }
  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()) } } }
  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)) } }
  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)) } } }
  66. Example @eldudi 66

  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
  68. Further read: » objc.io/issue-15 » github.com/paweldudek/good-tdd-stuff Getting in touch: »

    @eldudi » pawel@dudek.mobi @eldudi 68