Behaviour Driven Development - the whys and hows

Behaviour Driven Development - the whys and hows

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

April 20, 2015
Tweet

Transcript

  1. @eldudi Behavior Driven Development Paweł Dudek

  2. @eldudi What is a unit test? 2

  3. @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.” 3
  4. @eldudi Um… what? 4

  5. @eldudi “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 Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management.
  6. @eldudi What is an app? 6

  7. @eldudi An app is a set of behaviours created by

    programmer and expected by user. 7
  8. @eldudi We, programmers, have a limited cognition. As all humans

    do. 8
  9. @eldudi We can’t always ‘load’ all of the code of

    our app into our memory. 9
  10. @eldudi This means that we can, by accident, change the

    behaviour of the app. 10
  11. A 11

  12. A B 12

  13. A B 13

  14. A B C 14

  15. A B C 15

  16. @eldudi Preserving behaviour of complex systems is hard. In fact,

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

  18. @eldudi Unit test is a failsafe to make sure app

    behaviour is preserved. 18
  19. @eldudi They are a proof that all components if your

    app behave as expected 19
  20. @eldudi Sounds like tests are a godsend, doesn’t it? 20

  21. @eldudi What is a usual approach to testing? 21

  22. @eldudi Random Project Manager “Lets just write tests afterwards.” 22

  23. @eldudi No test harness 23

  24. @eldudi Providing a proof whether program works after it has

    been written increases burden on the programmer 24
  25. @eldudi “Programmer should let the correctness proof and program grow

    in hand.” –Edsger W. Dijkstra 25
  26. @eldudi –Edsger W. Dijkstra “If one first asks oneself what

    the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.” 26
  27. @eldudi Write failing test 27

  28. @eldudi Make it pass 28

  29. @eldudi Red, Green 29

  30. @eldudi Red, Green, Refactor 30

  31. @eldudi TDD is born 31

  32. @eldudi In TDD you always write test first. Always. 32

  33. @eldudi Which is then made green by writing/refactoring code 33

  34. @eldudi TDD is not “just adding tests first”. It’s a

    complete workflow. 34
  35. @eldudi TDD is a great way to determine how complex

    your code has become. You just have to listen. 35
  36. @eldudi Have to fake seven objects to isolate test? 36

  37. @eldudi Have to inject a fake into a fake into

    a fake? 37
  38. @eldudi Your test setup method has 70 lines? 38

  39. @eldudi This always points to an overcomplicated design And your

    tests are here to point that out. Very clearly 39
  40. @eldudi By writing test first you’re becoming a consumer of

    your upcoming API 40
  41. Is that API hard to test? 41

  42. That means it will probably be hard to consume too.

    42
  43. Or it will be really hard to maintain. 43

  44. @eldudi But TDD didn’t really answer all the questions 44

  45. @eldudi What should I test? 45

  46. @eldudi How to explain what given test is testing? 46

  47. @eldudi How to clarify requirements? 47

  48. @eldudi How to provide examples? 48

  49. @eldudi This is where BDD enters the stage 49

  50. @eldudi BDD is quite simple 50

  51. @eldudi But it requires a shift in how you perceive

    your test suite 51
  52. @eldudi When writing tests don’t think ‘tests’ 52

  53. @eldudi Think about ‘behaviours’ 53

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

  55. @eldudi An objects behaviour is defined by methods it declares

    in its interface 55
  56. @eldudi You should not be testing internal implementation of your

    object 56
  57. @eldudi BDD provides an ubiquitous language that helps understand what

    are the requirements 57
  58. @eldudi Example 58

  59. @eldudi Tools 59

  60. @eldudi Specta 60

  61. @eldudi Expecta 61

  62. @eldudi OCMockito 62

  63. @eldudi Let’s do it! 63

  64. What unit tests can’t do? 64

  65. Unit tests are never a guarantee that you won’t ship

    a bug. 65
  66. But they’re damn good at greatly reducing amount of bugs.

    And time spent on QA. 66
  67. Are unit tests an invaluable tool for writing great software?

    Heck yes.  Am I going to produce a poor product if I can’t unit test? Hell no. Jonathan Rasmusson 67 http://agilewarrior.wordpress.com/2012/10/06/its-not-about-the-unit-tests/
  68. @eldudi Thank you for your attention! 68

  69. @eldudi Resources & Contact @eldudi github.com/paweldudek pawel@dudek.mobi Resources Contact objc.io/issue-15