Upgrade to Pro — share decks privately, control downloads, hide ads and more …

BDD Mobilization

BDD Mobilization

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

Pawel Dudek

October 17, 2015
Tweet

More Decks by Pawel Dudek

Other Decks in Programming

Transcript

  1. @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
  2. @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.
  3. @eldudi An app is a set of behaviours created by

    programmer and expected by user. 10
  4. @eldudi –Wikipedia “A safety harness is a form of protective

    equipment designed to protect a person, animal, or object from injury or damage.” 22
  5. @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
  6. @eldudi TDD is a great way to determine how complex

    your code has become. You just have to listen. 32
  7. @eldudi This always points to an overcomplicated design And your

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

    what responsibilities given object should have. 38
  9. @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