Over the years Behavior Driven Development (BDD) has been increasing in popularity over many companies. Of course just because something is popular doesn’t mean it’s the right fit for everyone. I myself have worked at many different companies that utilized BDD, but like everything, they were used very differently. Over the course of this blog I want to address the common mistakes many first time users fall into when it comes to structure, process and reusability.
As the name suggests, BDD focuses on the Behavior of a particular feature. You would think that it’s easy to remember, it’s in the name right? But many times people fall into the trap of creating new feature files for every ticket or story scheduled. This in the end becomes a management nightmare. For examples, if your team completes about 15 stories in a two week sprint(Agile methodology), that’s about 360 stories a year for one team which includes a total of 360 feature files. The issue with this approach is that many stories will focus on the same feature, with slight modifications or maybe the story was just cleverly broken down into tiny achievable stories. For this very reason, its best for all that are involved to make additions to existing feature files versus just creating new ones.
Every team doesn’t always adopt all the best practices when it comes to the framework. The majority see the popularity and just want it used, but never take into account all that’s involved. In many cases it’s just used by developers. Although there is nothing wrong with this, the best approach I’ve experienced is when product, QA engineers, and developers work together. The best practices themselves call for team work. When product creates their stories they should include BDD like acceptance criteria for the developers to work on. This allows the developer(s) to write “failing” BDD tests, which should pass once the code has been implemented. This helps not only the developer(s) but product gets exactly what they were asking for. In the midst of all this is QA, creating all additional BDD tests. This of course should be reviewed by both product and the developers, this not only brings the team closer together but everyone will be on the same page. Even with clear acceptance criteria, things can be assumed or expected.
Depending on your team, even with the right foundation BDD, can be more difficult than other tools. A lot of difficulties a team can face come with being aware of all the steps already created. There is a discipline needed, to be actively involved with everything in the framework. BDD is some senses can be a keyword type of framework when done just right. Getting the team to be aware of those steps can be one of the biggest hurdles to get over, reuse as much as possible. BDD allows its users to write steps in plain free form English with just some minor formatting, but I’ve seen too many times where people get hung up on the actual steps. Since every step requires a “Given, When or Then” sometimes it’s easy to fall into the trap of thinking that those annotations are a part of the actual step.
So in conclusion BDD is a great tool, it might be difficult at times and definitely isn’t for everyone, but if used correctly can provide amazing coverage. With the knowledge of the common mistakes this should help avoid any headaches moving forward. For those that are just getting started, you should review my other blog BDD Patterns, which will help you understand feature files and step definition files in more detail.