What is API Testing

In the last post we discussed about UI automation and some of its disadvantages. Here we talk about what API level tests are and why to use them.

What are APIs

Application Programmable Interfaces (APIs) is an Interface to help a Program (client side programs like browsers, or any other program) access an Application. This way the main application is placed on a secure server where all the business logic works and connects with rest of the world using an API. To learn more about the basic concepts, this video will help.

APIs in the context of automation

Taking a step back from APIs, let’s illustrate here the different wheels turning behind the scene when a user, fills a form on a website for instance.

From the image above, when we perform UI automation, we are engaging the Application Under Test (AUT) from step 1 through step 8 all the way, hence another name for UI tests, end to end tests (end to end has a contextual meaning, more on that here). Alternatively, we can start our test from step 2 instead, and validate the response at step 7, which is generally called API / integration tests. We will be invoking every process along the control flow except steps 1 and 8. In other terms the ‘client-side’ scripting part is going to be ignored and rest of the application will be tested.

Automation pyramid

As we move from the database level to the browser level (step 4 to 1) automation is going to get more complex for automation and time consuming, with the advantage of testing more technology layers of the AUT. Similarly, in comparing automation from step 1 vs step 2, API tests are going to be less complex and easy to maintain, however we will forego testing certain portions of the AUT. This concept is captured in the phrase ‘Automation Pyramid’ illustrated below.

API level tests

Since we are not testing steps 1 & 8 we will simulate that functionality performed by our AUT to complete the flow of the application necessitating to understand how our client side scripts are generating messages (POST, GET etc.) sent to the server side. Also in the response, what values are we expecting to receive which would translate into the expected output on the browser’s interface.

Perhaps this might seem a bit tricky to work on, for most cases its way easier than it sounds. Developers simulate API calls and responses all the time to complete their development. A lot of efficient tools and methods are available to learn how the API is working without need for detailed documentation or insight from the product group (not to say you shouldn’t talk to the dev team, that would kill the whole purpose of testing. Rather it’s not that hard to understand an API from the outside to begin with).

Uses of API level tests

All the drawbacks we discussed in the previous post work to the advantage of API tests. These tests compared to UI tests take a lot less time to develop and maintain, more robust due to being less susceptible to change, execute way faster and allow the testers to cover a lot test coverage with the same amount of effort as well.

Business logic

Developers while building the application do not go through the whole control flow every time they test what they just coded. Instead the back-end developers working on the server side just test the API level messages being received and sent. Similarly, the front-end developers working on the client side (front end scripting) would also test their piece of code by simulating API messages. This makes testing both areas (front end and back end) less complex and quick.

What’s in all of this for the automation guy? We can break down a complex application’s automation into smaller and easier solutions. For applications which are huge, specially having a lot of business logic, it would be a nightmare to have decent code coverage from the UI level. API calls would make that job so much easier and effective.

Complex UI

Sometimes we run into problems on the UI level where certain elements on the web page are not recognized easily by the tool, or do not always perform the way it’s expected by the tool. These tests generally termed as ‘not automatable’ can be covered from API level tests since we don’t have to deal with the user interface level complexities.

Service virtualization

Many areas of the code need a very specific circumstance to execute which is sometimes very difficult from UI tests. Perhaps there are third party APIs involved, or some external hardware sending in data used by our application, or a piece of code which is scheduled for development in the future needs to be simulated for other teams to complete their feature set. We had a similar problem in one automation project where the server was supposed to receive input data from a hardware device which was still under development.

 On the API level this becomes way lot easier. Mostly in such cases the input / output of the API is defined. Lots of tools are out there which can simulate the required calls or responses. It’s then just a matter of constructing the calls properly and validating the expected responses. You might need to create a test harness using other tools / frameworks, but it’s a very powerful concept.

Input for UI tests

Creating pre-test data and / or removing it at the end of the test can becomes a problem. API level tests can be very effective for test data management. Again one or more structured API requests would do the trick in no time. Similarly, for deleting data which is no longer needed should be equally simple (except where business logic is complex enough blocking the removal of a record by simply one call).

Would love to hear what other uses you can think of API tests.