Understanding how the API-first approach affects testing

The API-First approach is a software development design approach that has become increasingly popular in recent years; so how can we utilise this to help us to improve quality whilst simultaneously improving the efficiency of our QA tests?

What is API-first?

Simply put, API-First is a software design approach whereby the API is designed and created first. This is done with a focus on considering the user's needs rather than just the application's integration needs. What this should mean, is that every data interaction within your application should be possible via the API2,3.

Why is API-first beneficial to development?

The main benefits of this approach are around reducing cost and increasing speed to market. If a company has one data set that many applications may need to access, then the API has already been taken care of and the application can utilise these rather than starting from scratch. Furthermore, the process of building APIs can be automated (eg openAPI), so these can be built relatively quickly.

What does traditional functional UI testing look like?

Many UI tests are written in black-box approach, where the author knows nothing about what’s underneath. Imagine a web application where you log your daily dog walks, you can fill in a form with details of how long you walked for, where you went and comments about the walk. A feature may be that you can edit a previous entry about a walk. A test may look something like this:

You may have another that looks like this:

Both tests are completely valid and test a genuine scenario, however, they both go through exactly the same steps to create the dog walk entry in the first place. This is done via the UI and can take a little time as our UI tests are waiting for elements to become available and may be going through multiple screens.

Automated UI tests are also prone to flakiness, with failures in things such as Webdriver, or simply network issues causing slow loads and failures. Even the most experienced Automation Tester can’t prevent external dependencies from causing issues within tests. Furthermore, UI testing tends to be expensive as it takes more time and resources than an API test.

How could we improve this in an API-first world?

Now imagine an API-First world. The API is treated as an important first step, therefore, when creating the APIs, there should be some functional testing around these. There may even be some user flow style tests to prove that the inputs and outputs of the APIs are working correctly together. For example, using the dog walking application concept from earlier, you could call an API to create a user, then with the user ID returned from this API, you could create a dog walking entry for that user.

If you used tools that were compatible with your UI testing tools, you could then call upon the test methods that have already been created for such APIs. The step in your test to create the dog walk entry still reads the same, but instead of going through multiple screens in the UI, it can simply call the API. The API has already been tested, so you know that it can be trusted. API testing also tends to suffer from less flakiness, so your tests are less likely to fail in the dependency setup stage of your test. You could use these APIs to do all of your test set-ups and teardowns and save a significant amount of time.

But are we still testing the application as the user would experience it, I hear you ask. Remember, the example given above would only be a subset of tests in a suite. The test suite should still be designed to go through each part of the application. The example suite above would also need to have a test that would go through the steps to create a dog walking entry via the UI and verify that this is working as expected. The difference here, is that the steps that would normally be repeated multiple times within a suite of tests are limited to the bare minimum. The method we are using to set up the test data is the same as what the application uses anyway as it all uses the APIs.

The above UI steps could be replaced with one API call:

To conclude

Now we have development teams using a software development design principle that leads to faster time to market and reduced costs. We also have the ability for the testing effort to make use of this to provide faster, more efficient testing, this can therefore be run more frequently, and in turn lead to a higher level of application quality.