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

4.

Questions

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

Resources

• http://pragprog.com/titles/achbd/the-rspec-book
• http://chariotsolutions.com/slides/pdfs/ete2008-IntegrationTestingWithRSpec.pdf
• Dan North talking about guidelines for writing solid features — http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/