Nowadays, to stay in the race, successful teams have to develop software faster with a high quality. That’s where Behavior Driven Development (BDD) comes in. It’s getting tremendous traction among DevOps and Agile teams. This methodology aims to align all stakeholders on shared understanding of the features to be developed through examples: BDD scenarios. While this approach is a lever for many DevOps teams, it can be hard to find the correct way to write scenarios. Indeed, everyone on the team should be able to understand what the feature does and the examples should provide help to automation teams to translate the scenarios in executable checks. In our teams, three attempts were necessary to find the right way to write our examples. Laurent Py and Vincent Prêtre share their best practices to write the scenarios. They tackle the pro and cons, and why their process did not follow real BDD guidelines.
The first attempt was mainly driven by developers. The scenarios were very technical, quick to automate, thanks to steps close to the GUI and easily reusable. However, those scenarios were useless at the product and business level, providing no information on the real behavior of the features. To solve that, we tried another approach where business and product people were writing the scenarios. Those scenarios described in detail what the behavior of the features was but they were harder to automate. We finally wrote automation code not generated from the BDD scenarios with potential discrepancies between what is executed by the CI tool and the original meaning of the features.
For the final attempt, the scenarios were written jointly by product, business and developers. We had definitely understood the key principle of BDD: discussion. This led to understandable and easily automated scenario. Alas, as our test base grew, the CI process took more time to run and instability of the tests grew along. We had to change our approach on automation and find the right level, mixing both backend implementation (extremely fast but not reflecting the real user experience) and GUI interaction (slow execution but reflecting how user really interacts with the product).