The practice of Behaviour-Driven Development (BDD) is often at odds with the practices commonly recommended, Joe Colantonio explains noticing six common problems and how to improve on these when sharing his own experiences and discussions with BDD thought leaders.
Keep your BDD implementation-free. Including implementation details, e.g. buttons from a GUI, will make the maintenance harder. Instead of on how, focus should be on what a user does. One way of doing this is to keep a more declarative instead of an imperative style when writing scenarios. Colantonio thinks one reason for teams including implementation details is that they try to use BDD as a test automation framework instead of as the collaboration tool it is.
Automation is a side benefit, not the reason for BDD. Colantonio refers to Seb Rose who has stated that when collaboration with people on the business or customer side fails it’s an anti-pattern to use BDD tools for test automation. Aslak Hellesøy, who created the BDD tool Cucumber in 2008, emphasizes that Cucumber first and foremost is a collaboration tool aiming for a common understanding across all members of a team. Cucumber features should be written before the code implementing the feature. When working with BDD writing examples, regression tests are a by-product, the testing is not the activity.
It’s about all about conversations. For Colantonio the beauty in BDD is that you get the chance to avoid incorrect assumptions and misunderstandings and to find potential bugs before writing code. He believes though that a focus on conversation instead of written down requirements may be a new reality for some teams and notes that teams moving to BDD and agile should be aware of not treating scenarios as requirements.
A scenario is not a requirement. They are related but in the form of a collection of scenarios corresponding to a requirement. Colantonio has found that treating a scenario as a requirement causes all kinds of issues and prefers the BDD way of creating small examples in discussion with the product owner, a technique described by Gojko Adzic e.g. in Specification by Example.
Don’t make everything a UI test. Scenarios are written from a user’s point of view but Colantonio notes that this doesn’t mean that functionality have to be tested through the UI, testing components inside of the UI in an application is both faster and less brittle. Earlier this year Konstantin Kudryashov explained how BDD can be used with Domain-Driven Design (DDD) to decrease the number of scenarios targeting the UI. By first proving the domain to work, only scenarios critical to the UI have to be added.
Doing Scrum doesn’t automatically mean you’re doing Agile. By doing Scrum teams too often think they automatically are also doing agile but Colantonio believes this is often not true. Writing unit tests after the code is written or writing some sort of acceptance or integration tests afterwards, maybe by a separate team, are signs that for him indicate that a team doesn’t have an agile approach.
