BDD Bialystok/Wroclaw

BDD Bialystok/Wroclaw

Presentation on BDD, architecture and testable code I've given at Mobile Bialystok in December 2016 and at LET Swift Wroclaw in January 2017.

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

January 19, 2017
Tweet

Transcript

  1. Behavior Driven Development

  2. None
  3. None
  4. None
  5. None
  6. Behavior Driven Development 6

  7. What is a unit test? @eldudi 7

  8. 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 8
  9. Um, what? @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. What is an app? @eldudi 11

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

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

    @eldudi 13
  14. We can’t always ‘load’ all of the code of our

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

    of the app. @eldudi 15
  16. Preserving behavior of complex systems is hard. In fact, of

    any system at all. @eldudi 16
  17. Enter unit tests. @eldudi 17

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

    is preserved. @eldudi 18
  19. Test Driven Development @eldudi 19

  20. Tests drive the way you code @eldudi 20

  21. Always write test first @eldudi 21

  22. Tests influence architecture of your app @eldudi 22

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

    23
  24. There is no such thing as untestable behavior Only untestable

    code @eldudi 24
  25. Have to simulate behavior of your dependency dependency dependency? @eldudi

    25
  26. Need to fake seven objects? @eldudi 26

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

    27
  28. Hard to specify clear requirements? @eldudi 28

  29. Overcomplicated design @eldudi 29

  30. Thinked-through design @eldudi 30

  31. First consumer of your API @eldudi 31

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

    code @eldudi 32
  33. What is testable code? @eldudi 33

  34. Testable code == Good Architecture @eldudi 34

  35. What is good architecture? @eldudi 35

  36. Cohesion @eldudi 36

  37. Coupling @eldudi 37

  38. Good design A simple definition @eldudi 38

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

    composable » Context independent @eldudi 39
  40. Good architecture - principles » Single responsibility » Few dependencies

    » Depend on interfaces, not classes (yay POP!) @eldudi 40
  41. @eldudi 41

  42. !!! @eldudi 42

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

  44. SOLID @eldudi 44

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

  47. Behavior Driven Development Test Driven Development @eldudi 47

  48. What's the difference? @eldudi 48

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

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

    50
  51. When writing tests don’t think ‘tests’ @eldudi 51

  52. Think about ‘behaviors’ @eldudi 52

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

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

    its interface @eldudi 54
  55. You should not be testing internal implementation of your object

    Only its interface @eldudi 55
  56. Work outside-in @eldudi 56

  57. Ubiquitous language @eldudi 57

  58. Quick & Nimble @eldudi 58

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

    { expect(Dolphin().isFriendly).to(beTruthy()) } it("is smart") { expect(Dolphin().isSmart).to(beTruthy()) } } } @eldudi 59
  60. 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()) } } } @eldudi 60
  61. 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()) } } } @eldudi 61
  62. describe("its click") { context("when the dolphin is not near anything

    interesting") { it("is only emitted once") { expect(dolphin!.click().count).to(equal(1)) } } 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)) } } } @eldudi 62
  63. Example @eldudi 63

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

    @eldudi » pawel@dudek.mobi @eldudi 65