The Automation Testing Pyramid is something we use to describe the most effective and efficient way for just about any business wanting to use Test Automation for Quality Assurance. You can read more about the Pyramid and why we use it here.

Following on from my article series on Unit Testing, this article will discuss the virtues of API Testing: what it is, what it’s used for, and why it’s important.

What is an API?

An API (Application Programming Interface) is a way to define interactions between different kinds of software. In Modern applications this is used to communicate information between a User Interface (front-end) and a Back-end server, allowing developers to keep their business logic away from prying eyes and deliver only the necessary information to the user. APIs are usually comprised of small and quick interactions, taking upwards of 300 milliseconds (dependant on distance from the server). In practice we find that lots of processes which need to be tested are being handled through APIs, and if we test it through the UI we are simply calling the request and reacting to the response, this provides us an opportunity for efficiency.

How do we test using APIs?

If we have a set of end-to-end processes which are all handled through API requests, as testers we can eliminate the front end from our test and simply make all the requests ourselves. This has become popular through tools like Postman or SoapUI, and even non-technical testers can create API tests which run much faster than UI tests and don’t have any dependencies on the validity of the UI. Whilst these tools are popular you will always get more bang for your buck if you use a coded solution, as these provide more customisation. It is important to remember that coded solutions require skills and time investments, but this will ultimately pay off in the long run.

Whether using Code or a Codeless tool API testing is a simple process of:

• Collecting all the relevant data for the test.
• Making a request which consumes the data.
• Awaiting a response from the server.
• Finally validating using a set of acceptance criteria.

These request-response pairs can be chained together, using the data provided by the first response in the second request and so forth, into an end-to-end scenario.

What should we be testing using APIs?

• Non-Functional
  • Heartbeat APIs – these are APIs which indicate that the application has been deployed and is running successfully. Having API tests which indicate this is incredibly useful when deploying your application to a new environment.
  • Response Times – if your APIs are not working quickly then your application will appear to be slow. Identifying when a back-end server is taking too long to respond can help increase the quality of your application.
  • Response Format Validity – ensuring that responses are formatted correctly will make it easier to debug issues when you start doing acceptance testing and help speed up the process of root cause analysis.
• Functional
  • Endpoints – Each function on an API is referred to as an Endpoint, and will return a Status Code, and in some cases a Body of data. If we test each Endpoint with multiple scenarios and a set of acceptance criteria, we can have confidence that our data is being processed correctly by the back-end server.
  • End-To-End – APIs are very advantageous when you have multiple scenarios of an End-To-End process which all must be tested. Instead of having to go through the lengthy, and brittle process of UI Testing you can push your data-driven scenarios through an API suite and have your results in a nth of the time.

What shouldn’t we test using APIs?

• External integrations – unless the request is required in an End-To-End process you should only be testing Endpoints that are developed by your team!

What are the benefits of API testing?

• Quick results
• Non-flaky tests (not reliant on the UI)
• DevOps compatible tests – ie. Heartbeat tests
• Information about your infrastructure – measuring response times can help improve or find the issues in your infrastructure.

What is not covered by API tests?

If all your testing was done at the API layer, you would have certainty that your data is processed correctly but you would not have certainty that your users can navigate through and interact correctly with your application. API tests by their nature do not cover your UI risks, and therefore you should have a mix of UI and API tests.

An Example

Inspired Testing has successfully implemented API testing at a large Insurance company in a application for generating insurance quotes. This is a very data heavy application, which needs to calculate quotes with a very high degree of accuracy. The basic user scenario requires lots of data capture, and eventually validating that the quotes were generated accurately at a quote and member level. From an automated UI perspective, we are seeing approximately 4 minutes to capture data, 2 minutes to wait for the quote to generate and 30 seconds to validate 120,000 excel cells. This is made more complicated by the different testing scenarios (140 difference sets of data) and is an ideal candidate for API testing. After pushing these tests down to the API layer, we reduced the 4-minute data capture to 20 seconds - this is an easy win – it has not replaced our UI tests as we still need to ensure the front-end is usable but when we need to check all the scenarios the API tests win hands down.

What should you take away from this?

API tests are a fantastic way to test your applications data handling and processing. If you are looking at a bulk, data-driven test scenarios your immediate reaction should be to create an API suite. But it is also important to remember that the front-end cannot be ignored and sanity tests should be put in place to cover these risks

API tests can be implemented through codeless tools to augment your existing manual testing, but these are limited to the feature suite of your chosen tool. Coded solutions provide freedom and customisability – but require code related skills and knowledge.

Either way, if all your tests are sitting at the UI layer you should consider moving your data or process heavy tests down to the API layer.

About Steve

Stephen Beck joined Inspired Testing in 2016 and has worked as an Automation Tester, Trainer, Team Lead and Delivery Manager within the Cape Town Delivery Centre. He has worked to provide Automation Testing solutions for multiple clients, as well as overseeing project delivery. He has also worked on creating, maintaining, and updating the tools used by Inspired Testing to ensure that clients are provided with effective Test Automation solutions.