Tuesday, 03 April 2018
APIs are the building blocks of applications and allow data to be exchanged independently of one another in composite applications and service oriented architectures (SOA). The API layer provides a range of services and data to applications, enabling business logic to be defined in a standard and open framework so the services can be provided centrally to where they are needed.
With SOA applications there is often a need to test the API level separately, in order to obtain the maximum confidence in this vital layer as early as possible so that applications are built on solid foundations.
It is generally not possible to test all API business logic through the user interface; APIs are often made available for multiple applications and testing for one may not cover the way APIs are used by others.
The most common types of APIs in use today are Web Services and REST.
This article discusses API testing, the challenges involved and tools and techniques that allow it to be carried out.
API Testing
API Testing, also known as Service Testing or Headless Testing, is designed to test systems consisting of API components, without using the GUI.
The main area of API involvement is the Application/Web Service layer, where testing focuses on the verification and validation of components that integrate with each other without any issues. Directly testing the API rather than the GUI allows a wide range of combinations of data to be tested, often prior to the delivery of the integrated system, meaning more thorough testing can be carried out earlier.
Obtaining the right level of coverage for input/output schemas is an important topic while planning API testing. APIs usually have a range of parameters, both mandatory and optional, which affect the actions performed on the inputs to a transaction and thus the expected results. It is important to identify all the parameters that are possible, and those that are likely to be used, ideally with a priority assigned to each one – so that the most important tests can be run first.
The main challenges of API testing can be divided into four categories:
- Parameter Selection: the selection depends on the business requirements, and as a result the coverage should be applied accordingly. For example if a new parameter is added to the request, then coverage will increase with all the combinations of the new parameter.
- Parameter Combinations: there are various combinations of input parameters, which can end up with a huge number of possible tests. The number will increase with each additional optional parameter to be tested.
- Call Sequencing: in addition to testing each API individually, the expected sequence also needs to be considered when planning API level tests. For example, the output of one API could be taken as an input of other API.
- Request Data Combination: every parameter is designed to have a specific value which needs to be validated. Parameter values can be numeric (number range) or string (length restrictions) and they need to be enforced in testing, if they are missed out they can become problematic from the end user perspective.
The above challenges in API testing can be overcome by modification of the related test cases as soon as the change is made to the parameters (such as adding/removing parameters, request/response change, etc.)
Is API Testing the Same as Unit Testing?
API and Unit testing do have similarities, but they are not the same thing. Unit testing is typically a “white box” activity performed by developers and target a single module. Where that module is dependent on other modules, these are simulated as they are often not available at the time of Unit Test.
Testing APIs at the System level normally includes a number of integrated modules and APIs, including the actually delivered components rather than simulated versions.
Although it is a separate phase, collaboration with the development team is key when considering API testing, especially if the associated documentation is not complete, as is often the case with systems still under development.
API testing is a more technical discipline than traditional GUI testing and as well as the tools to run the tests, requires good technical knowledge of the underlying architecture and all the possible parameters.
API Testing tools
There are many tools on the market, including both Enterprise and Open Source options. The choice of tool depends on a number of factors, including:
- Type of APIs to be tested
- Any tools already in place that the new software should integrate with
- Budget
- Technology stack of the applications/architecture
- Company policy and standards (particularly around adoption of Open Source technologies)
Examples of API testing tools include the following:
- Micro Focus UFT (Enterprise)
- Parasoft SOAtest (Enterprise)
- SoapUI (Open Source)
- Google Test (Open Source)
APIs very often make use of Extensible Markup Language (XML) files for exchange of information. Tools like XMLSpy can be useful when viewing these files and checking for formatting discrepancies.
API testing tools tend to be designed for a specific environment, for example web services, REST, development language or application specific. API testing is highly suited to automated functional testing, due to the large number of combinations of data and parameters possible.
Conclusion
API testing for today’s applications is often an important part of the process and can enable thorough testing to be carried out at a technical level across a wide range of parameters and inputs, independently of an application’s user interface.
This can significantly increase the quality of the end product and ensure that the foundation of multiple applications is functionally correct at an early stage of development.
API testing can be carried out by both developers and testers and there are a range of tools available to suit all applications, architectures and budgets.
Find out more
To find out more about API testing, or to talk to our team about implementing a test automation solution to include API level validation, please contact us for a no-obligation chat.
