'How to deal with abstract Given steps in BDD?
At the base of our application is a big configuration set, which defines abstract groups of devices and they are omnipresent as part of the Gherkin scenarios.
Now we used Given steps like this as part of our Gherkin specification:
Given the device is a Zebra
Zebra in this case is just a placeholder for the actual group, but it includes many different specific devices. A statement like this is incredibly convenient, but it also makes this scenario untestable since you would have to automatically execute this scenario for every specific device and I don't know of any framework that would have such a feature. And scenario outlines are also not a solution since you would have a copy of this device list in almost all scenarios and/or feature files.
Are there any possible solutions to this problem. Maybe we are completely wrong to use BDD like that, but how can you deal with this kind of configuration problem?
Solution 1:[1]
If you're looking to just set up a context (your device list) before all scenarios of a specific type, then this is a really great example of background context; long-lived data that rarely changes and is present for all scenarios. Many BDD frameworks provide tools to enable you to set up the background at the top of the feature / scenario file. Cucumber for instance has Background; JBehave does it with GivenStories.
For frameworks that don't provide such a tool, it's OK to skip the detail of the step, as long as it's well-understood to everyone working with it. So you could for instance say:
Given the standard device list
And a Zebra from that list
That would allow you to do it with only a couple of lines, with the detail of the device list hidden in the step definitions.
If however you're looking to try and run the scenario for each device just to check that it works, then that's probably outside the scope of BDD, and certainly of BDD frameworks.
BDD isn't really about rigorous regression testing. It's about capturing concrete examples of how a system behaves, preferably through conversations with experts (the people who understand the problem, like business representatives), testers, and developers. If you have an example of one device behaving in a particular way it's usually enough to capture that understanding, at least from the perspective of BDD.
If you have to perform a scenario for every single device just to be thorough then it's OK to use something like JUnit instead. You can still use the Given / When / Then syntax if you want to, either as comments in the code or by creating your own DSL, but if you find other ways to express the value of the tests then don't be constrained by BDD's syntax or BDD tools. It isn't the only way to test things.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Lunivore |