Using BDD in API automation testing is a good apro

问题:

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?

回答1:

I am currently using BDD for RestAPI Testing. Here is pros and cons for BDD RestAPI Automation framework.

Technology We used: Cucumber,Java,Rest-Assured and junit

Following pros and cons are my own comment or personal view. It is based on my experience.

Pros:

• Easy to write feature file using Gherkin language
• It is very easy to cover Acceptance criteria
• Everyone in team (Including team ) Can help you to write feature file
• Very good reporting format and debug failures
• Easy to execute during nightly or regular build
• Integration testing is very easy as You can use Background or Given and other feature of Gherkin language

Cons:

• When other team member in company need test case or any documentation than your answer will be "We have scenario in Gherkin Language" and it is sometime hard to understand/explain scenario as there is no clear step like traditional step definition or big documentation

• Higher management have high time to understand converge of testing product like HP ALM Coverage report.

• It is little hard to write for few sprint specially for those who write test case for years.

Please free to edit or suggest anything need to add or remove. I hope it will help you.

回答2:

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.

回答3:

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

回答4:

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.

回答5:

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.

回答6:

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.

回答7:

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.