BDD is a collaboration practice: you describe business rules, examples of these rules, and acceptance criteria that illustrate these rules. Some of these acceptance criteria can be potentially automated.
Detailed API testing (e.g. testing CRUD functionalities, error codes, JSON format etc.) is rarely of much interest to the business, so it generally makes little sense to use Gherkin to express them - it just adds an extra layer of complexity. Lower level tools such as RestAssured do the job just fine. And testing REST APIs with any JavaScript test library is pretty trivial. So if your team finds it more efficient to write REST API tests with a tool like Karate, that's great! But it ain't BDD, and it's not the only game in town.
The only exception is where you might use Cucumber as a communication tool between developers across teams, as a more expressive way to describe and document API contracts. But you can do this with contract testing tools as well, though it may not be as readable.
Let me know your thoughts in the comments!
Top comments (0)