| References | |
|---|---|
| (Why you do it) BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. (What is it) “It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”  |
|
Overview | |
|---|---|
| Behaviour-driven development (BDD) is an evolution of the ideas behind agile software delivery. With its roots in test-driven development, domain-driven design, and automated acceptance testing, BDD focuses on the ways an application is expected to work - its behaviour. Dan North and Liz Keogh introduce the principles behind BDD and describe how it works in practice. We provide an overview of the methodology of BDD: understanding your domain and who your stakeholders are, identifying and exploring requirements, automating acceptance criteria, and delivering working and tested software. BDD is writing software that matters |
Expanding the BDD concepts
Outside-in: understand system usage from the outside (user interfaces) inwards
Pull based system: produce only that which is ready to be used by people, systems, or code closer to a boundary or UI
Multiple stakeholder: Core and incidental stakeholders - Core stakeholders define the vision and often provide budget; Incidental stakeholders support the solution delivery and may influence that solution
Multiple scale: BDD applied from end to end, from small feature set to enterprise projects
High automation: automation of testing (acceptance & unit) hence reducing the expense of scenario and examples testing; Enabling and inviting change through acceptance tests and reducing the impact of change
Features: a slice through the whole solution; defined by multiple scenarios describing interactions stemming from user interface (outside-in). Features are defined with respect to business value.
Feature Injection: only work on features that deliver value, according to the project vision/goals (in the context of the organisations goals)
Ubiquitous language: using the langauge of the domain consistently, end to end in the solution artefacts; name things with respect to their behavior in the domain. Using Given,When,Then also provides structure to the ubiquitous language.
Identifying value
Table Stakes / Commodity
Differentiators
Spoilers
Research & Development
Feature Injection
Breaking the model - Chris Matts
http://en.wikipedia.org/wiki/Unknown_unknown
http://en.wikipedia.org/wiki/Black_swan_theory
Writing features with respect to value
Defining Features
Features are defined with respect to the value they deliver to the business, thus allowing easier discussions regarding the priority of each feature. In BDD, features are defined as follows:
In order to (deliver some business value)
As a (role / stakeholder)
I want to (carry out some action)
Simple feature example
In order to sell pets
As the pet shop owner
I want to register new pets as they arrive
Defining Scenarios
Scenarios provide more depth to the features in BDD and expand on the status and actions that will take place in that feature. In BDD, senarios are defined using the Given, When, Then approach:
Given (a specific situation)
When (some action or event takes place)
Then (some outcome occurs)
You can also use And to add additional conditions our outcomes to When and Then.
Simple Example
Given a rabbit called Snowy
When I register the rabbit with a price of £25
Then Snowy should be available for sale
Example scenarios from LeanKitKanban feature requests
Here are some scenarios I submitted as feature request for the online kanban boards available from LeanKitKanban.com.
Given I am editing a card's details
And that card has a relationship to another card
When I select related cards
Then I am given a list of current cards by title, optionally sorted by type (defect, feature, task, etc) and vertical swim lane
Given I am selecting a related card
When I select one or more card titles from the list of all cards
Then the selected card titles appear on the card currently being edited (either on details tab or new related tab)
Given I am selecting a related card
When I select one or more card titles from the list of all cards
And the relationship is selected as two way
Then the selected card titles appear on the card currently being edited (either on details tab or new related tab)
And the current card title appears on all the selected cards either on details tab or new related tab)
Given I am viewing the card details of a card that is related to one or more other cards
When I select the title of one of the related cards
Then I see the details of that related card
And am still able to edit the card details of the card from which the related card was selected.
Automating acceptance tests with JBehave
... work in progress ...
Mock Objects with Mockito
... work in progress ...
Posts
