BDD & Rest API automation

Question

When I search for BDD and Rest API automation. I get lots of examples where some user scripts a human-readable user story which shows how to use his API. This user calls it BDD.

But BDD based not only on instrument to write BDD automation.

BDD is a process which connects together analytics, customers and programmers together.

From my point of view the key of BDD is a user story.

When I write this:

@Positive @Get @User
Scenario: Show twitter user
  Given I access the resource url "/1/users/show.json?screen_name=jasonh_n_austin&include_entities=true"
  When I retrieve the results
  Then the status code should be 200
  And it should have the field "name" containing the value "Jason Harmon"
  And it should have the field "id" containing the value "57005215"

I dont see here a User. I see a couple of http requests and checks.

So the question is: is it really okay to use bdd tools to automate testing of Rest API or this is usless and better to script your tests on plain code?

Answer 1

Short answer is yes. It is really okay to use bdd tools to automate testing of a Rest API

UI testing involves HTML, JavaScript and a DOM. The BDD should describe behavior. Given, When, Then statements that describe actions like click a button miss the point of BDD. What behavior are you trying to test? The application could change the actions that implement that behavior but good BDD would still be valid.

So where are the actions? In the step definitions? I say that actions like button clicking should be encapsulated in page objects. The step definitions that implement the Given, When, Then statements contain the assertions, control logic and the calls to page objects requesting behavior. The page object methods should reflect behavior. The page object methods translate behavior into actions such as button clicks.

Which brings me to my point.

API actions replace page actions! Instead of interrogating a DOM you send HTTP requests and/or parse an HTTP response block. Or you issue SQL to a back end database, warehouse or business intelligence.

So the BDD is much the same for API testing as it is for UI testing. API testing replaces page objects with API objects.

Answer 2

You can certainly use BDD to test a REST API as Mike has mentioned. The advantage is that the test will read like an "executable business specification" that the end customer is more likely to understand. But the consequence is that you will need to write the "glue code" that translates the "natural language" of the spec into raw, HTTP calls. And one of the hardest parts of this especially when you use a language like Java is the business of traversing JSON (or XML) and asserting for expected results.

For teams that are more focused on creating API "platform" services, BDD may be not worth the effort. Such teams are more concerned about whether the HTTP requests are well-formed, the headers are correct and that the data payloads (request and responses) are valid and as expected.

Karate (disclaimer: I am the dev) is a new open-source framework that is built on Cucumber, so it inherits the BDD syntax, but allows you to have full control over HTTP. This is a trade-off which is summarized in this table: (link)

In conclusion, Karate is an approach that is in the middle, it is not pure BDD, but it is a level above having to form HTTP and traverse JSON by hand, in "plain code".