Bahaviour Driven Development


Published on

My Behaviour Driven Development slides from the .net user group in wellington on october 21st 2009

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Bahaviour Driven Development

    1. 1. Behaviour Driven Development owen evans, developer @buildmaster
    2. 2. Behaviour Driven Development • What is BDD? • A rethinking and repurposing of existing methodologies • A second generation Agile Technique • A companion to other techniques such as TDD and XP
    3. 3. A Combination of Disciplines • TDD • Test first methodology • But a focus on value • Defining value up front • XP/Scrum/<Insert ‘Agile’ methodology here> • Close communication with all stakeholders • Common language definition to aid communication
    4. 4. A Focus On Value • TDD says only one thing: Test First • Tests alone do not drive value • Tests are not deliverables • Tests can be crap • BDD says: only do what needs to be done (and test first)
    5. 5. What needs to be done? • Test driven specification/Acceptance Test Driven Design • All systems can be defined by their behaviour [says BDD] • The behaviour is what makes a system usable/crap • We can use required behaviour to drive development
    6. 6. Features (come from agile stories)
    7. 7. Example: STEP ONE THE Feature Feature As a Cake Lover I want to be able to turn on my Acme Cake Maker So that I can start making great cakes
    8. 8. The Feature • Broken into three elements: • the actor (Cake Lover) • the action (turn on cake maker) • the motivation (want to start making cakes)
    9. 9. Why? • The actor gives us a stakeholder, this is who we’re providing value to • The action allows us to drive functionality • The motivation allows us to tell when we’re done
    10. 10. Example part 2: The Scenario(s) Scenario Given there the cake maker is not switched on When I press the “on” button Then the machine should say “welcome to the Acme Cake Maker” And the machine should ask me which cake type I want to make
    11. 11. Scenarios • Scenarios are always 1st person • We want to design in terms of the stakeholder • We want to see that we are providing them value
    12. 12. What does this give us? • BDD has three main tenants: • Enough is Enough • Just do what’s needed no more • Deliver Stakeholder Value • Everything we do should be tracable to value to a stakeholder • It’s All Behaviour • We can alwys describe code in terms of it’s behaviours
    13. 13. Remember • A stakeholder isn’t necessarily a human • it can be a company goal • it can be required API’s • it can be other developers (ok they might be human) • Stakeholder ≠ customer
    14. 14. Great... WTF? • How do we apply this • BDD has inspired many tools
    15. 15. ATDD* Tools *Acceptance Test Driven Design
    16. 16. FitNesse Granddaddy of Acceptance Testing Tools. A wiki formed around Ward Cunningham’s Framework for Integrated Testing (FIT)
    17. 17. • Pros: • Language agnostic (runners for most major languages) • Wiki Syntax is easy to learn and use • Cons: • Doesn’t support BDD syntax easily/natively • Fit style tests can be quite cumbersome when setting up complex objects
    18. 18. Story Q Nunit Based Runner for Stories
    19. 19. Story Q • Pros: • native c# • native support for BDD • quick integration with testing tools • Cons • Code based (only output is stakeholder readable) • Syntax can be hard
    20. 20. Cucumber A Ruby BDD Specification Runner Part of the RSpec Ruby Testing Framework
    21. 21. • Pros: • Feature rich • Native support for BDD syntax • Plain text runner (sharable specifications) • Cons: • Ruby only
    22. 22. Unit Testing
    23. 23. • Keep to your framework of choice • • Nunit • MBUnit • also many frameworks to help use a more BDD syntax • NBehave, NSpecify, Machine.Specifications
    24. 24. How does this all fit together • Concentric feedback circles: • Step 1 write the acceptance test(s) using Given When Then syntax • Step 2: Make sure they fail (red-green-refactor cycle) • Step 3: Write unit test on first part of code (this is just TDD), and make sure it fails • Step 4: Make test pass, does Acceptance test pass? • Yes go to step 1, No go to step 3
    25. 25. In Pictures Focus on one scenario 1. Write Failing step definition drop into unit tests 2. Write failing unit test 3. Get the test to pass 4. Refactor 5. Once Acceptance Test Step is passing 6. Refactor 7. Repeat 2-6 till acceptance test is complete and passes Write next acceptance test
    26. 26. Take aways • BDD is not about tooling • BDD focuses on three tenants • Enough is Enough • Always deliver value • Everything can be expressed as behaviour • BDD is only part of the arsenal
    27. 27. Great resources • Cucumber and RSpec are thought leading frameworks so read the RSpec Book • achbd/the-rspec-book • BDD mailing list • behaviordrivendevelopment
    28. 28. FIN me: Twitter: @Buildmaster Blog: