Learning from

@tonybruce77 and @andrewjutton

mistakes with BDD

Setting the scene

• Big Greenfield project.

• Transitioning the way we work in general.

• Introducing BDD.

1) Write scenarios as a team

• Don’t get one person to write them! It’s not all about one persons view.

Scenario: Select InsurerGiven that an insurer is not selectedWhen that insurer is selectedThen that insurer is displayed as selected

Scenario: Deselect InsurerGiven that an insurer is selectedWhen that insurer is deselectedThen that insurer is displayed as deselected

2) Include the SME’s, domain experts and customers

• These guys understand the problem domain more than anyone.

3) Don’t spend hours arguing about the correct language to use

• Try and land a few ground rules early.

4) Don’t include implementation details in scenarios

• Avoid tying scenarios to the UI by referencing page elements or controls.

Scenario: Display ‘Insurer Selection’ screenGiven that Insurer selection screen has been invokedWhen the Insurer selection UI is renderedThen the ‘Insurer Selection’ page is displayedAnd the ‘Risk Variation Name’ field is displayedAnd the ‘Risk Variation Name’ field is selectedAnd the ‘Customer Name’ is displayedAnd only breadcrumb ‘Select Insurer’ is displayedAnd all insurers setup in the system for the policy type are displayedAnd all insurers setup in the system for the policy type are not selectedAnd the ‘Next’ button is disabled

5) Keep scenarios precise

• No one will read or understand a 20-30 line scenario.

6) Don’t rush into automation

• It’s not all about the tool and automated tests can be a big overhead.

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.

8) Use your scenarios

• You’ve put the time in to write the scenarios, use them!

9) Every scenario is negotiable

• Everything is subject to change.

http://www.lastexittonowhere.com

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.

11) Living Documentation

• Make this available to the whole business.

12) Drive the sprint review meeting through the scenarios

• A story may only be considered complete when all your scenarios have been implemented.

13) See what others are doing

• That’s why we’re all here.

14) Have the conversation!

• Get the whole team in a room and just talk through the requirements.

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

Thank you