# API Testing

## Summary


Applications today rely on APIs. Whether it's a web client requesting a service from a web application server, or one microservice requesting data or operation from another microservice, APIs play a key role. Via APIs, developers give others access to their service. 

At the same time, organizations are embracing Agile methodology and making frequent product releases. It's therefore important to test these APIs. 

API testing is useful to validate a solution and to find errors. API testing complements unit testing and end-to-end testing. It enables more efficient use of test resources. Problems can be caught earlier in the development cycle.

HTTP RESTful API is the most widely used architecture. However, this article describes API testing in general and is therefore relevant to other API types such as SOAP or GWT RPC.

## Discussion

### Do I need API testing for my application?

A web application typically consists of three layers: user interface, business logic and database. End-to-end testing would test all layers of the app but it's also slower. Problems are hard to isolate. Business logic may need many tests, for which we will end up unnecessarily exercising the UI in the same way. Moreover, end-to-end testing can begin only when all layers are available. API testing solves this problem by bypassing the UI. It executes tests at the service or business layer. 

While unit tests are typically written by developers and take a white-box testing approach, API tests are usually written by the QA team and view the system under test (SUT) as a black box. However, not everyone agrees on this division of roles. Some feel that developers should do API testing since they created the APIs. Others say that since APIs specify a contract, they need to be validated by testers. 

While unit tests exercise the business logic directly, API tests go through the API layer. 


### What's the flow for a typical API test?

An API test first calls an API endpoint, which is really a URL. HTTP headers are set as required for the test. The type of HTTP request may be GET, POST, PUT, DELETE, etc. With each of these, the necessary data is sent to the API endpoint. 

Once a response is received, the response code and contents are validated. HTTP headers that specify access control, content type, or server might be validated. 

In a sequence of API calls, some parts of a response may be used for the next API call. For example, a POST request might return an identifier. A subsequent GET request might verify that the response includes this identifier. 

API testing is generally black-box testing. We don't look at what happens behind the API server. We only validate the responses. But sometimes we may want to validate if an API request triggers another API request or updates the database. For example, an API request may trigger a request to Google Maps API. During testing, we could mock Google Maps API and validate the request made to the mocked API. 


### What are the possible benefits of API testing?

Since data is exchanged in standard formats (XML, JSON), API testing is language agnostic. Any programming language can be used to create API tests. API responses can be easily validated since most languages have libraries to compare data in these formats. 

End-to-end testing can't be done unless all parts of the application are ready. With API testing, the business logic can be tested early on even when the GUI is still under development. This also facilitates easier end-to-end testing at a later stage. 

Because APIs are usually well specified, API testing leads to high test coverage. Moreover, UI changes often during development. API tests based on well-defined specifications are easier to maintain. 

API testing is faster than UI testing. More tests can be performed in a shorter time. Releases can happen faster. When an API test fails, it's easier to find the source of failure. API testing also enables automation of CI/CD pipelines. 


### What types of tests are possible at the API layer?

A wide variety of tests can be done at the API layer, both functional and non-functional:  

    + Validation and functional tests ensure that APIs behave as desired and deliver specific functionalities.
    + Security and penetration tests would consider user authentication or authorization, threat detection, and data encryption.
    + Load testing checks app performance at normal and peak loading conditions, or if throttling is correctly applied at theoretical maximum load. For example, we may want to know how many API requests can be served per minute with a specific response time.
    + Tests can be designed to check for runtime errors, resource leaks and general monitoring of the app.
    + Fuzz tests include random data in API requests. App is expected to be robust against such requests.
    + UI events and interactions trigger API calls. Thus, UI testing is also an approach to API testing.
    + Since APIs interface various services, they play a key role in integration testing. However, they're also useful in end-to-end testing to validate dataflows across services.

### What are some best practices for API testing?

Before creating API tests, document and understand the API. This should include API purpose, application workflows, supported integrations, and so on. 

Some tools for API testing include ReadyAPI, AcceIQ, Katalon, SoapUI, Postman, Apigee, JMeter, REST-assured, and more. Manual API testing could be a starting point. Tools such as Postman can help create tests manually, save them, and replay them later. For automated API testing, adopt an automation framework such as Robot Framework. 

Create client code and components that can be reused across many tests. Write clear tests so that debugging and maintenance is easier. Organize each test into three parts: setup, execution and teardown. It should be possible to configure tests for different environments or customer requirements. 

Write tests in a modular fashion. For example, user authentication and password change can be two separate tests, and the latter can be made dependent on the former. 

Measure how long each test takes. This can help in scheduling tests. Schedule tests to execute every day. When a test fails, make the failure state explicit in the response or report. Test system should record failures for later analysis. 

## Milestones

2000

While APIs existed in earlier decades, the early 2000s mark the birth of modern APIs. During this time companies such as Salesforce, eBay and Amazon popularize the use of APIs. In these APIs, the use of XML data format becomes common. 

Dec  
2009

Mike Cohn makes the point that test automation must be done at the correct level. He identifies three levels: unit, service and UI. He visualizes these into a **test automation pyramid**. We wish to do lots of unit testing and as little UI testing as possible. API testing happens in between and avoids unnecessary repetitions of the same UI actions. Although he calls the middle layer the service layer, it's not restricted to just service-oriented architecture (SOA). 

2018

Since API specifications are formal, and with the recent progress of Natural Language Processing (NLP), some tools such as Functionize explore the possibility of automatically generating API tests from the specifications. This takes test automation to another level so that human testers can focus on exploratory and security tests.