Behavior Driven Development

Raw Notes

  • Behavior-Driven Development is comprised of:
    • Acceptance Test-Driven Planning
      • "Thou shalt write acceptance tests no later than the Iteration Planning Meeting." (often before)
        • ==> clarifies our definition of "done"
          • ==> Improves the quality of our estimates.
    • Test-Driven Development
      • "Thou shalt write unit tests before writing the code."
        • ==> ensures only required features are developed ==>
      • "then, write the code you wish you had."
        • ==> ensures that the API is sensible (because you're crafting the contract from the consumer's side, biasing it from that perspective)
  • BDD can be thought of as "Outside-in" development — from the visible parts down in.
  • Acceptance Criteria (scenarios in Cucumber "features"):
    • are executable (making "done" supported by a mechanism)
    • are used during estimation sessions and iteration planning to clarify scope
  • The User Story template "As a [role], I want to [feature], so that [benefit]" is known as the "Connextra format"
    • extend or abandon this format when more context is needed (e.g. describing an algorithm)
  • DRY Principle — "every piece of knowledge in a system should have one authoritative, unambiguous representation."
  • RSpec Authoring Guideliness
    • a few expectations as feasible per example (given as "1-to-1")
      • ==> gives better fidelity as to what's failing since each example is run.

BDD Workflow with Cucumber and RSpec on Rails

1. As a BA, write the .feature, complete with as many Scenarios that are needed
2. As a Developer, picking up a Story, find the corresponding .feature and mark the first Scenario as @wip
3. Run cucumber through rake:

$ rake cucumber:wip



What's the difference between a "mock" and a "test double" (or a "stub" or "fake" or "spy")?


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License