Why BDD is very applicable to API test frameworks?

Published in

PEXA API

3 min readJul 5, 2019

Many people still think BDD is for user interface testing. Well I was one of them 5 years ago, until I met a QA leader on a work trip who was big on agile, BDD, API’s and automated testing. He made me aware that BDD works well with with API/service level tests. In fact, BDD automated tests for micro services are easier to write, maintain and faster to run than the user interface (UI) acceptance tests.

Why to adopt BDD for micro service testing in first place?

With the rise of Artificial Intelligence, Internet of things, Open API’s and API monetisation; organisations are exposing their API’s and micro services to third parties, so it becomes really important to understand your API’s. BDD is great technique to document the functionality you expose to your customers. BDD is essentially executable specifications/requirements that are glued to the actual tests through code.

Approach to writing good BDD for API/micro services:

There are two approaches to write BDD for service level tests. It largely depends on who the target audience is. The first approach is to write BDD in high level business language which a user or business person could understand and the second approach is bit technical which is more suited for the more technical audience like developers, testers and solution designers.

I feel the approach which puts the business first is the most effective and the underlying technicalities of pay loads, parameters , setting headers etc can be hidden in the code behind.

A practical example:

Feature: Navigate to closest fuel station near meIn order to get home and not be stranded
  As a car driver 
  I want to navigate to closest fuel station to my current location

Look at this feature definition. I didn’t even need to explain what the feature does!

Scenario Outline: All the fuel stations within a given distance should be shownGiven Tom is at <lat> <long>
When he looks for the closest fuel station within <radiusInKm>
Then <numberOfFuelStations> fuel stations should be found
 
  Examples:
    | lat       | long        | radiusInKm | numberOfFuelStations |
    | -37.814   | 144.96332   | 5          | 2                    |
    | -24.815   | 112.96332   | 10         | 4                    |
    | -14.815   | 113.96332   | 15         | 8                    |

The above scenario makes so much sense to a product/business owner!

Now lets take a more techie example of writing a BDD:

Scenario: Should get all closest fuel stations within a given distance
  When I call Get on /fuelStations with parameters:
    | lat       | long      | radiusInKm |
    | -37.814   | 144.96332 | 5          |
  Then I should get a response that contains at least 5 'fuelstation' entries
  And the response should contain 'fuelStations' data:
    """
      {
        id: "fuelStation_127676",
        url: "https://MyFuelApp/FuelStation/fuelrank_5901",
        distance: 5Km,
        fuelStaionBrand: "Seven Eleven Brighton",
        lat: -39.814,
        lon: -156.96332
      }
    """

Hmm, bit of gibberish to a product owner but an OK approach for the techies if these are only the internal API’s. Being a techie, it’s still quite hard for me to read this, especially when I am coming back to it after the test development.

Summary:

If you are working with open API’s or API’s which are exposed to third parties BDD is a great way to document what your API’s do so that you can tell your customers on the know-how.

Coming next:

Well this is getting bit long so I think I need to divide in two parts. Part two will be a bit more technical. Stay tuned!

Why BDD is very applicable to API test frameworks?

Written by Jag Singh