API testing best practices

This is the second post in a three-part series on API testing. The first post, which can be found here, provided a brief introduction on APIs, API testing and its relevance to the testing world. This post will feature some best practices for everybody involved in API testing. The third and final post will contain some useful code example for those of you looking to build your own automated API testing framework.

As was mentioned in the first post in this mini-series, API test execution differs from user interface-based testing since APIs are designed for communication between systems or system components rather than between a system or system component and a human being. This introduces some challenges to testing APIs, which I will try to tackle here.

API communication
Whereas a lot of testing on the user interface level is still done by hand (and rightfully so), this is impossible for API testing; you need a tool to communicate with APIs. There are a lot of tools available on the market. Some of the best known tools that are specifically targeted towards API testing are:

I have extensive experience with SOAtest and limited experience with SoapUI and can vouch for their usefulness in API testing.

Structuring tests
An API usually consists of several methods or operations that can be tested individually as well as through the setup of test scenarios. These test scenarios are usually constructed by stringing together multiple API calls. I suggest a three step approach to testing any API:

  1. Perform syntax testing of individual methods or operations
  2. Perform functional testing of individual methods or operations
  3. Construct and execute test scenarios

Syntax testing
This type of testing is performed to check whether the method or operation accepts correct input and rejects incorrect input. For example, syntax testing determines whether:

  • Leaving mandatory fields empty results in an error
  • Optional fields are accepted as expected
  • Filling fields with incorrect data types (for example, putting a text value into an integer field) results in an error

Functional testing of individual operations or methods
This type of testing is performed to check whether the method or operations performs its intended action correctly. For example:

  • Is calculation X performed correctly when calling operation / method Y with parameters A, B and C?
  • Is data stored correctly for future use when calling a setter method?
  • Does calling a getter method retrieve the correct information?

Test scenarios
Finally, when individual methods or operations have been tested successfully, method calls can be strung together to emulate business processes, For example:
API test scenarios
You see that this approach is not unlike user interface-based testing, where you first test individual components for their correct behaviour before executing end-to-end test scenarios.

API virtualization
When testing systems of interconnected components, the availability of some of the components required for testing might be limited at the time of testing (or they might not be available at all). Reasons for limited availability of a component might be:

  • The component itself is not yet developed
  • The component features insufficient or otherwise unusable test data
  • The component is shared with other teams and therefore cannot be freely used

In any of these cases, virtualization of the API can be a valuable solution, enabling testing to continue as planned. Several levels of API virtualization exist:

  • Mocking – This is normally done for code objects using a framework such as Mockito
  • Stubbing – this is used to create a simple emulation of an API, mostly used for SOAP and REST web services
  • Virtualization – This is the most advanced technique of the three, enabling the simulation of behaviour of complex components, including back-end database connectivity and transport protocols other than HTTP

Non-functional testing
As with all software components, APIs can (and should!) be tested for characteristics other than functionality. Some of the most important nonfunctional API test types that should at least be considered are:

  • Security testing – is the API accessible to those who are allowed to use it and inaccessible to those without the correct permissions?
  • Performance – Especially for web services: are the response times acceptable, even under a high load?
  • Interoperability and connectivity – can be API be consumed in the agreed manner and does it connect to other components as expected?

Most of the high-end API testing tools offer solutions for execution of these (and many other types of) nonfunctional test types.

More useful API testing best practices can again be found in the API Testing Dojo.

Do you have any additional API testing best practices you would like to share with the world?

10 thoughts on “API testing best practices

    • Hi Madhumita, thank you for your kind words!

      A post containing more details about the differences between mocking, stubbing and virtualization is on my to do list, so watch this space 🙂

    • Hi Ravi,

      if you’re referring to an interface in the API sense, I can’t explain it better than is done on Wikipedia: interface and API.

      If you’re referring to an interface in the object oriented programming world, here’s a good definition.

      You can’t instantiate an interface by the way, in neither sense of the term.

  1. Hi Bas,

    Its very nice article. Recently I am working with API testing, i have very minimal knowledge about this concept. In my opinion when API test automation should be done , do we need to develop automation code in same manner of developers do. For ex: one of api testing fetches some customer details from the database. This is webservice developed by developers. In order to test this i need to supply customer number from the database by fetching dynamically and also reading customer details from Database and validating w.r.to webservice output. In this process from test team as well i am developing automation code in the parallel to Dev team. But its more effort , is this right approach or wrong approach. Please let me know how do you want me to build api test automation in this scenario.

    • Hey,

      This sounds like a very sensible approach. If the web service does nothing more than fetching data from the database and returning it in a certain format (JSON or XML), you could even test most of it in unit tests where the actual database layer is mocked. Add one or two integration tests that validate the interaction with an actual database and you’re all set.

  2. Hi Bas,

    This is the most valuable article series/blog that i have come across in the means of API Testing. it is very helpful and understandable as i am very new and passionate to the API Testing methodologies.

    Please post more articles like this in the future, while enriching software testing. (y)


Leave a Reply

Your email address will not be published. Required fields are marked *