Behavior Driven Development can be used for both frontend and backend, but in both cases, without a strong foundation things can get out of hand really quickly. To establish the foundation, the user should fully understand how the feature file work and how it ties to the step definitions. Over the course of this blog I want to focus on the patterns of how feature files so they don’t seem intimidating or confusing. As well as how step definitions are created and how the they interact with the feature file when tests get executed.
When first being introduced to BDD, writing a feature file looks very simple. But let’s look at how BDD actually looks at the feature file level so we can fully understand what’s going on. For myself, I like to think of cucumber(framework to execute BDD feature files) as a parser, each step is just that, a step. The great thing about cucumber on a feature file level, is that it’s all the same regardless of language implementation, ruby, java, js, or otherwise. This is because works off the annotations Given, When, Then, And, and But. These annotations are seen in only one way to cucumber, a step, and every step has a string value ties to a step definition via regular expressions. But understanding that each annotation is just a step, you should never treat it as such. Each of the annotations have a specific purpose to the user, it’s just framework only cares about the regular expression when being executed.
Writing step definitions are pretty simple but could be hard to understand when first getting started. Depending on the programming language, it’s pretty much all the same, just code like you would in any other tool. The only difference is the syntax for the method, which can be super easy for everyone, just run the automation and an empty method for each step will be displayed to you (only the steps that are missing code). You can then copy and paste it into your file and start coding. The method that’s given to you will show a “Given, When, or Then” annotation, but like I mentioned before it’s just an identifier. Think of it like it like a tag, which is searchable at execution. What will really happen when the feature file is run is that it will stop at each annotation and look up the regular expression for the current step. This allows cucumber to look up all the methods in the framework based on a simple string. So if you think about it, it’s like any other programming language, but it allows non-technical people to write the method names.
The transitions to this type of framework can be tough and difficult at first, but once you break it down and understand the patterns, it becomes easy. Adoption for any one particular group in a project is the easy part, full adoption to include all – product, QA and Dev is the overall goal. Many great things have come before BDD and some even based on it such as BBT, but I would suggest trying it out first, see if it’s the right fit for you and your team before fully investing.