What are the pros & cons of BDD testing?

Question

I want to build up automation tests for the software I'm working on as a QA. I don't have much experience in that field, I'm still freshly graduated and I don't know all the good habits behind Automated tests, my question is about Behavior Driven Development combined to Automated tests.

I was reading that some QA recommend to write test with Selenium combining BDD (Behavior Driven Development) with frameworks like Cucumber, lettuce or radish for example.

BDD looks like a good thing to do if I want to involve everyone in the process and make easier the understanding of my tests but it seems to take more time as well

What's your opinion on BDD and Automated tests, do you use that or is it something that you don't use for some reasons?

Answer 1

I think the pros of BDD are captured in a very good way by a user djojo in his answer - in this SO post - all credits to him

I totally agree the communication is one of the biggest advantage however the benefits are for all the parties involved and the advantages for those are different.

So briefly:

For All:

• living documentation
• collaboration, early discovery of unknowns
• enforce building domain vocabulary and semi formal language (DSL) to express system behaviour consistently within the organization.

For devs:

• like TDD, it helps to think in chunks, create nice and testable code.
• write code for what is needed only (build the right thing)
• better coordination between different dev teams developing similar features with different technologies.

For QA:

• ready acceptance criteria
• ready building blocks for all kind of tests
• test what is exactly need (test the right thing)

For PO:

• think and reason features in detail thus produce better specs
• better visual and coordination with other Managers and Product owners
• better visual and understanding on Devs and QAs output/report due to the same source/format of specs

Also, this link has an excellent documentation about the same topic

One of the biggest pro of BDD is the biggest con also. Since communication is essential between the parties - user/client and the development team, absence of any one of them, can cause the process to have ambiguities and lack of answers to the questions/doubts raised by either side.

Answer 2

In theory BDD sounds great. In practice, product owners and developers rarely continue to use BDD past the initial 3-6 months. At pretty much every company I have worked at, BDD inevitably became an extra layer of abstraction which QA engineers had to maintain and the rest of the company did not participate in.

So my advice is that if you try to move your company to BDD, get the buy in of upper management first. Make sure they are committed to enforcing the DSL and requirements and specifications are written in BDD.

Answer 3

There are a lot of benefits of BDD but at the same time it is not a good choice for short projects or projects where the velocity of tests implementation is very point. Implementation of BDD scenarios is an additional abstraction level and it takes some time, I have described pros and cons in this article