The SQA2 Blog: General
BDD Foundation
Behavior Driven Development can be used for both frontend and backend. 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 feature files work and how it ties to step definitions. Over the course of this blog I want to focus on the patterns of how feature files work. This will make them less intimidating or confusing. I will also cover creating step definitions, including how they interact with the feature file during test execution.
During an introduction 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 it works from the annotations: Given, When, Then, And, and But. Cucumber see the annotations only one way, as a step. And, every step has a string value tied 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 has a specific purpose to the user. The framework only cares about the regular expression during execution.
Start with an empty method
Writing step definitions is fairly simple. However, they can be hard to understand when getting started. Depending on the programming language, it’s pretty much all the same, just code like you would in any other tool. The syntax for the method is the only difference. And, with a little trick, it can be super easy for everyone.
Simply run the automation and an empty method for each step is 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 given to you shows a “Given, When, or Then” annotation. As 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. It just also allows non-technical people to write the method names.
Identify the patterns
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.
