BDD Mobilization

BDD Mobilization

Talk from Mobilization 2015 Edition http://2015.mobilization.pl/#when-where

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

October 17, 2015
Tweet

Transcript

  1. @eldudi Behavior Driven Development Paweł Dudek

  2. @eldudi

  3. @eldudi

  4. @eldudi Behavior Driven Development Paweł Dudek

  5. @eldudi What is a unit test? 5

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

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

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

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

    do. 11
  12. @eldudi We can’t always ‘load’ all of the code of

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

    behaviour of the app. 13
  14. @eldudi Preserving behaviour of complex systems is hard. In fact,

    of any system at all. 14
  15. @eldudi Enter unit tests. 15

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

    behaviour is preserved. 16
  17. @eldudi They are a proof that all components in your

    app behave as expected 17
  18. @eldudi What is a usual approach to testing? 18

  19. @eldudi Random Project Manager “Who needs units tests anyway?” 19

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

    20
  21. @eldudi No test harness 21

  22. @eldudi –Wikipedia “A safety harness is a form of protective

    equipment designed to protect a person, animal, or object from injury or damage.” 22
  23. @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.” 23
  24. @eldudi Write failing test 24

  25. @eldudi Make it pass 25

  26. @eldudi Red, Green 26

  27. @eldudi Red, Green, Refactor 27

  28. @eldudi TDD is born 28

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

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

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

    complete workflow. 31
  32. @eldudi TDD is a great way to determine how complex

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

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

    a fake? 34
  35. @eldudi Your test setup method has 70 lines? 35

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

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

    your upcoming API 37
  38. @eldudi By writing the test first, you're forced into thinking

    what responsibilities given object should have. 38
  39. @eldudi Let’s sidetrack a bit 39

  40. @eldudi What should I test? 40

  41. @eldudi How to explain what is being tested? 41

  42. @eldudi How to clarify requirements? 42

  43. @eldudi If you have questions like this - don’t worry.

    You’re not alone.
  44. @eldudi In fact, lots of people had this problems. And

    they still have it. 44
  45. @eldudi Best TDD practitioners already had an answer 45

  46. @eldudi This is how BDD was created 46

  47. @eldudi BDD is quite simple 47

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

    your test suite 48
  49. @eldudi When writing tests don’t think ‘tests’ 49

  50. @eldudi Think about ‘behaviours’ 50

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

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

    in its interface 52
  53. @eldudi You should not be testing internal implementation of your

    object 53
  54. @eldudi Work outside-in 54

  55. @eldudi Use an ubiquitous language that helps understand what are

    the requirements 55
  56. @eldudi Example 56

  57. @eldudi What unit tests can’t do? 57

  58. @eldudi Unit tests are never a guarantee that you won’t

    ship a bug. 58
  59. @eldudi But they’re damn good at greatly reducing amount of

    bugs. And time spent on QA. 59
  60. @eldudi Quick recap 60

  61. @eldudi BDD • Think examples/behaviors, not tests • Provide examples

    how your object should behave • Don’t test implementation, work outside-in • Use ubiquitous language to make examples easily understandable 61
  62. @eldudi Benefits? Robust codebase. Less bugs. More time for features!

    62
  63. @eldudi Go build great stuff! 63

  64. @eldudi Thank you for your attention! 64

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

    65
  66. @eldudi Lunch time! 66