Behaviour Driven Development - Mobile Trends

Behaviour Driven Development - Mobile Trends

Slides from presentation given at [Mobile Trends](http://www.2016.mobiletrends.pl)

15633e65c96546d830fb84ee7fe5db9c?s=128

Pawel Dudek

February 19, 2016
Tweet

Transcript

  1. @eldudi Behavior Driven Development Paweł Dudek

  2. None
  3. @eldudi Behavior Driven Development Paweł Dudek

  4. @eldudi What is a unit test? 4

  5. @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.” 5
  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. @eldudi Preserving behaviour of complex systems is hard. In fact,

    of any system at all. 11
  12. @eldudi Enter unit tests. 12

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

    behaviour is preserved. 13
  14. @eldudi TDD 14

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

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

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

    complete workflow. 17
  18. @eldudi TDD is a great way to determine how complex

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

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

    a fake? 20
  21. @eldudi Your test setup method has 70 lines? 21

  22. @eldudi You need to simulate five events to test one

    method? 22
  23. @eldudi This always points to an overcomplicated design And your

    tests are here to point that out. Very clearly 23
  24. @eldudi By writing the test first, you're forced into thinking

    what responsibilities given object should have. 24
  25. @eldudi By writing test first you’re becoming a consumer of

    your upcoming API 25
  26. @eldudi SOLID 26

  27. @eldudi BDD 27

  28. @eldudi What should I test? 28

  29. @eldudi If you asked this question - don’t worry. You’re

    not alone.
  30. @eldudi BDD is quite simple 30

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

    your test suite 31
  32. @eldudi When writing tests don’t think ‘tests’ 32

  33. @eldudi Think about ‘behaviors’ 33

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

  35. @eldudi An objects behavior is defined by methods it declares

    in its interface 35
  36. @eldudi You should not be testing internal implementation of your

    object 36
  37. @eldudi Work outside-in 37

  38. @eldudi Use examples to clarify requirements 38

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

    the requirements 39
  40. @eldudi Example 40

  41. @eldudi Recap 41

  42. @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 42
  43. @eldudi Resources & Contact @eldudi github.com/paweldudek pawel@dudek.mobi Resources Contact objc.io/issue-15

    43