People tend to use BDD-tools for everything those days… Don’t get me wrong behavior driven development is a great way of software design, but it’s not -just- a testing tool! It’s a way of collaboration and it aims to reduce misunderstandings.
Aslak Hellesøy, Founder Cucumber Ltd,wrote a very good blogpost about it, where he pointed out some very good points. (https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html)
When using BDD-tools you’re implementing several extra layers in your testautomation code, which you need to maintain. (Both Gherkin features and step definitions) So, if you use it just for specifying testscript then you introduce extra waste.
Like Aslak already wrote, it can be justified if it improves collaboration and reduces misunderstandings, but if the tool is of testing purpose only those benefits will obviously never happen.
I also like his point about many testers fallen in the same trap…
…they use Cucumber uniquely as a testing tool. No collaboration. No outside-in. They write Cucumber scenarios after the software instead of the other way around. Doing BDD well leads to decoupled software, which again makes it easy to reduce the duration of tests. You don’t get any of these benefits when you treat Cucumber as an afterthought. Personally I have seen many companies using BDD as an afterthought. Often they come up with the argument that ‘everybody can write the feature files’, however they don’t look at the long term effect. Because maintenance can be hell.
I hope you all read the blogpost of Aslak Hellesøy and decide to use BDD in a proper (collaborative) way or decide to not use BDD at all.
It still seems to be a very popular tool, just because things get very readable for non-techie people. They are still a lot of drawbacks: duplicates code, scenario’s written in plain text, extra abstraction layers, etc… JGiven tries to solve some of those drawbacks, as they state on there website:
- Scenarios are written in plain Java with a fluent Java API – Neither text files, nor Groovy is needed
- Method names are parsed at runtime and define the scenario text – No duplicate text in annotations is needed
- Scenarios are executed by either JUnit or TestNG – No extra test runner is needed, thus JGiven works with all existing IDEs and build tools for Java out-of-the-box
- Scenarios are composed of multiple, reusable so-called Stage classes – No more test code duplication
- Scenarios and steps can be parameterized for writing data-driven tests
- JGiven generates HTML reports that can be read and understand by domain experts and serve as a living documentation
So, try to use code driven BDD frameworks, if you have to use BDD-tooling, because you can apply all kinds of development practices. (… and it just makes it easier)