Using BDD in API automation testing is a good apro

Question

I'm writing a framework for RESTful API test automation, I already decided to go with REST Assured, I'm not 100% sure about add a layer to allow define tests using a domain specific language like Gherkin, therefore adding a BDD framework like Cucumber. What is your opinion?
Is a good approach to use BDD in API automation testing?

Answer 1

I am working on API automation from last 3 years using BDDs. It is quite simple and reusable concept which gives a clear vision to anyone even to a non-technical person also. The only part which we have maintain here is header data which include header and cookies to maintain a session.

I must suggest this approach as it is really result oriented and easy to maintain and reuse.

Answer 2

I did manage to combine automated UI testing and BDD (Concordion) for clients a couple of years back. The bigger challenge was and still is HTML code with div and other tags that can easily change when the web design does. For the BDD solution one should also decide what they like best, FIT, Cucumber, Concordion,... there are several solutions out there.

Answer 3

It depends on your project, if your project is large and getting larger day by day and you want maximum integration or functionality test coverage then I can suggest you to use BDD. In this case you will have to define only step definitions for each and every modular task and create test cases using those step definitions in feature files.

Answer 4

Have implemented cucumber with selenium : Java, TestNG framework as well as SpecFlow, NUnit, Selenium: POM and Extent Reports framework. With my past experience, This has offered the ability to enlarge the pool of input and feedback from business users and SME s who have no technical development background. With this expanded feedback we were able to deliver faster and better. Had fewer or no surprises during UAT and release because the application code was a derivative of the feature files and not interpretation of the requirements. This made continuous integration and deployment happen faster. I look forward to implementing this in my current project.

Answer 5

On my opinion using BDD is always a good approach (in terms of testing automation).

1. Easy to share with other devs. Sets of human readable scenarios will faster enter the ropes.
2. CI Integration with BDD will makes failures investigation easier.
3. Easy maintain and refactored because your method name is not only "assertUserHasRoLe" f.e. but also with business meaningful text

BDD is like a bridge, higher level of abstraction in your test framework. And instead or reading the test code of what is going on in that method - thats should be enough just to read behaviour definition of that method.

Answer 6

No, it is not a good approach for API testing, and even for UI testing many things have to "line up" for you to be successful with BDD.

I have written a detailed explanation as an answer to another question on Stack Overflow, here is the link:

https://stackoverflow.com/a/47799207/143475