BDD NL

My talk on BDD from Cocoaheads NL given on 15.03.2017

Transcript

1. Behavior Driven Development
4. cocoa_nl_20
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