Behavior-driven development (BDD) is an agile development process that encourages teams to share tools and a process to collaborate on software development projects across developers, QA folks, and business stakeholders. Sounds good, right? I mean, who wouldn’t want to be more collaborative and transparent with all project stakeholders? I believe there is tremendous value in this type of approach.
However, people choose to use BDD tools for many different reasons—and in my experience, they’re often the wrong reasons. In certain cases, BDD tools are likely to do more harm than good. Can you be successful with BDD tools? Yes. But often, how it should work doesn’t reflect how it usually does work.
The overall theme of my talks is to figure out ways to make your testing initiatives more difficult to fail. It is important to keep things simple with fewer moving parts and more and useful abstractions. BDD tools generally fail when it comes to making things easier to maintain.
I recently hosted a STP webinar called “The Hidden Costs of BDD Tools.” I shared my views on how the allure of using Cucumber or other “Given/When/Then” code wrappers seems greater than ever, but that there is a fairly narrow path to success. In the webinar, I talked about the various reasons why people choose to use BDD tools as well as what the reality looks like for many companies. I also revealed some of the inherent underlying issues with BDD tooling, including why teams so often end up in trouble when using them, and discussed some alternatives for how to get the most out of your UI testing. If you’re interested in BDD, it’s worth your time to watch the webinar.
As you can imagine, BDD can be a hot topic! We got many questions and were only able to get to a few of them during the live event, so I decided to take some of the other questions and answer them right here in this handy blog post. You can also check out some of the conversations with these questions on Twitter.
What is your suggestion for how to best get started using the BDD approach?
If you don’t know how or why to use a BDD tool: don’t use it. If you want to practice BDD, first you need to make sure your manager, product team and developers are all on board.
Have you found any good tools/frameworks that provide documentation outside of relying on the "Clean Code" (code is readable) perspective?
That really depends on what you are trying to document. I’d love to have “Backward BDD” tooling that generates the information people are interested in from the code, rather than having the user do it from the other direction.
Any suggestions on how to "undo" a BDD setup?
First, copy/paste the actual code into methods. Next, abstract out anything imperative into Page and Data Objects.
The BDD tool worked great because there was no deep expertise on coding and I think Cucumber provides a layer (non-business) that allows them to be more effective.
The only problem is that these tools don’t avoid the need to write good code. That still has to happen. If your goal is to give less technical people busywork, sure; but this will not improve your test strategy.
What would be a non-BDD alternative to a Screenplay pattern promoted by Serenity BDD?
I’ve never seen an example, but would be interested in seeing one. Also, I prefer Atomic/Autonomous/Short DOM to Database tests which PO pattern supports and Screenplay does not.
I also have seen all sorts of wrong usage of BDD, but TBH... I've also seen that elsewhere.
Definitely important to keep in mind that browser automation is hard! Selenium provides some specific challenges that require domain knowledge and technical prowess to address.
What's the difference between Cucumber and Gauge?
The difference is I haven’t used Gauge before. My BDD tooling talk applies to any software that does some form of translating English language to code.
What is your preferred alternative to the flexibility of Cucumber's tags for running various subsets of tests? What's your preferred alternative for the functionality Cucumber's profiles provide?
This functionality will vary based on Test Runner. RSpec definitely supports these things in Ruby; I would be surprised if most test runners in other languages did not have similar functionality.
Can you give an example of when you've seen BDD tools used successfully where they provide real value?
Depends on what you mean by “success” and “real value.” I mentioned the scenario of a consultant providing “agile transformation” within a company/team being useful, but that’s a specific (and temporary) context.
What is your thought for data testing in capturing these requirements?
Data Driven Testing doesn’t belong in a DOM to Database test. Make sure the form works, then any investigation into what the data entry does in your system should be at a lower level.
What tool do you recommend for data testing to capture requirements?
A REST client in the language of your choice.
How do you feel about [the Geb/Spock] implementation of BDD over Cucumber (i.e. where the feature file is not separate, but is the outline for the test case implementation)?
I’m definitely a fan of distinguishing between Arrange, Act and Assert statements; so long as it isn’t doing natural language translation it sounds great.
Is it possible to develop a tool that is more like a wizard that guides you through the process?
There are codeless solutions out there, but most of what I’ve seen only handles the easier use cases and generates its own maintenance costs. One of them might be “good enough” for what you need.
For a tester who is trying to bridge the manual to automation gap...where to start? Many job listings mention Cucumber-Gherkin.
Manual testers who only know how to write Gherkin statements won’t have great job security, in my opinion. There really isn’t a way to escape the need for writing good code, so your best bet is to find resources to become a good developer in the first place.
Do you have a BDD question that I didn’t answer here? Hit me up on Twitter (@titusfortner), and check the hashtag #TitusOnBDD to see some of the other questions I’ve answered there.