Slides from presentation given at CukeUp 2012. This presentation discussed a number of lessons that had been learned applying BDD for the first time to a new Greenfield project. The presentation was given by Andrew Jutton & Tony Bruce on the 4th April 2012.

1. Learning from mistakes with BDD
@tonybruce77 and @andrewjutton

2. Setting the scene
• Big Greenfield project.
• Transitioning the way we work in general.
• Introducing BDD.

3. 1) Write scenarios as a team
• Don’t get one person to write them! It’s not all
about one persons view.
Scenario: Select Insurer
Given that an insurer is not selected
When that insurer is selected
Then that insurer is displayed as selected
Scenario: Deselect Insurer
Given that an insurer is selected
When that insurer is deselected
Then that insurer is displayed as deselected

4. 2) Include the SME’s, domain experts
and customers
• These guys understand the problem domain
more than anyone.

5. 3) Don’t spend hours arguing about
the correct language to use
• Try and land a few ground rules early.

6. 4) Don’t include implementation
details in scenarios
• Avoid tying scenarios to the UI by referencing
page elements or controls.
Scenario: Display ‘Insurer Selection’ screen
Given that Insurer selection screen has been invoked
When the Insurer selection UI is rendered
Then the ‘Insurer Selection’ page is displayed
And the ‘Risk Variation Name’ field is displayed
And the ‘Risk Variation Name’ field is selected
And the ‘Customer Name’ is displayed
And only breadcrumb ‘Select Insurer’ is displayed
And all insurers setup in the system for the policy type are displayed
And all insurers setup in the system for the policy type are not selected
And the ‘Next’ button is disabled

7. 5) Keep scenarios precise
• No one will read or understand a 20-30 line
scenario.

8. 6) Don’t rush into automation
• It’s not all about the tool and automated tests
can be a big overhead.

9. 7) Execute the tests as part of your CI
process as early as possible
• Get the tests running as part of the build as
soon as possible, this keeps the test alive.

10. 8) Use your scenarios
• You’ve put the time in to write the scenarios,
use them!

11. 9) Every scenario is negotiable
• Everything is subject to change.
http://www.lastexittonowhere.com

12. 10) Use examples to reinforce the
scenarios
• Examples bring scenarios to life! They make
them dynamic and they provide test data to
verify that the scenario meets it’s goal.

13. 11) Living Documentation
• Make this available to the whole business.

14. 12) Drive the sprint review meeting
through the scenarios
• A story may only be considered complete
when all your scenarios have been
implemented.

15. 13) See what others are doing
• That’s why we’re all here.

16. 14) Have the conversation!
• Get the whole team in a room and just talk
through the requirements.

17. Summary
• Started to write the scenarios more collaboratively as a
team.
• We are learning from mistakes
– The language evolves, it is not instant
• More developers are more interested
– Slowly more examples being written
• Working together more
– Business getting move involved
• Helps clear up miscommunication and ambiguity
• Can add value without the automation
– Slowly adding more automation
• Helps enable teamwork

18. Thank you