Behaviour Driven Development (BDD) is an evolution of test-driven development that places explicit emphasis on language, communication and 'outside-in' development. Many people are familiar with the 'Given,When,Then' structure used in BDD specifications (or acceptance tests) but is that really where it ends? In this session Antony Marcano gives a short intro to BDD, explains 'outside-in' development. Using a metaphor from learning theory and HCI principles, he'll show you how to go beyond 'Given,When,Then' to a shared understanding of
your customer's needs.
4. BDD Origins ‘The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!”… I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls. My response is behaviour-driven development (BDD). Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.’ -Dan North
5. BDD Origins - Shortened “ Behaviour Driven Development (BDD) builds upon Test-Driven Development (TDD) by formalising the good habits of the best TDD practitioners. ” – The Cucumber Book, AslakHellesøy, Matt Wynne
6. Some ‘Good Habits’ Slice Vertically Work from the outside-in One example at a time
8. 2009 8 Traditionally, development is sliced horizontally Private albums Share photos Create album Login User Story C User Story B User Story D User Story A Software Components (modules/classes) Software Components (modules/classes) Iteration n Iteration x Iteration n+1… Sprint n Sprint x Sprint n+1… time time …but defers feedback (often, until it’s too late)
9. 2009 9 Vertical slicing Private albums Share photos Create album Login Share photos Create album Share photos Software Components (modules/classes) Iteration n Iteration x Iteration n+1 time …results in earlier feedback
14. Implement story driving with unit tests Scenario should pass Have a conversation For each Example illustrating the story Elaborate as an automated scenario (aka acceptance test) When all Scenarios pass, story is done (almost) One example at a time Test should fail
16. Given When Then Given <some initial context> When <something happens> Then <some expectation>
17. Given When Then Given <some initial context> [and some additional context] When <something happens> [and something else happens] Then <some expectation> [and some more expectations]
18. A Typical Illustration Scenario: Login Successfully Given I am on the home-page When I enter the username ‘antony’ And I enter the password ‘p4$$w0rd’ And I click ‘login’ Then I should be logged in What’s wrong with this example?
19. A Better Illustration Scenario: Login Successfully When I login as ‘antony’ with the password ‘p4$$w0rd’ Then I should be logged in Why is it better?
21. Pitching it right… Goals e.g. Withdraw Cash Tasks Identify to bank Request amount (inter)actions Insert Card Enter Pin Press “Withdraw Cash” Enter amount Press OK } Just right } Too low level
22. For example… When Iadd, the number ‘2’ and the number ’3’ task } actions http://cukesalad.info
23. Some nice side-effects Encourages description of UI interactions in one place Makes it easier to execute scenarios via different interfaces
Requirements are given to BA as examplesBA infers Abstract RulesDevelopers code Abstract Rules (they test by inferring examples from the rules)Testers use BA rules and the software to infer new examples (edge cases)
At this point we should demonstrate so people can follow
