In the field of software test engineering, API testing is one of the most important and sought after requirements for any application or system.
This article covers:
- the aspects of API testing at operational level
- the challenges in API testing
- the features of an API testing tool
Operational aspects of API testing
Functional (System)
Functional testing of an API is done to validate the correctness of the API response for a given request. For any given method, API response is what needs to be validated. Response is not only the response body, but also the returned status code.
Integration
Many times an API is meant to call another API or trigger another action. In these cases, performing an overall call sequencing and validating them at the same time would be considered as integration testing.
Security
As the name suggests, security testing of APIs deals with the security of the API under test. Let it be about who is calling the API (client or other application), can the requested data be manipulated before reaching the server, and the response data be securely transferred to the requesting party? It is about validating the implemented security mechanisms like Basic Authorization, OAuth or two-way authentication.
Performance
Performance testing of an API is performed in various scenarios depending on the requirements.
- Load testing – Calling an API for a number of requests (expected load) and monitoring the responsiveness for various metrics such as response time or throughput
- Stress testing – Calling an API for a number of requests beyond the verified limit of the number of calls an API can comfortably handle
- Endurance testing – Calling an API with a fixed number of requests for a longer period and monitoring for responsiveness
In all these scenarios, it is vital to keep an eye while monitoring the responsiveness of the APIs for the part that is causing issues. End goal is always to figure out these issues, fix them, retest the same scenarios for the fixes and repeat until it is considered satisfactory.
API Protocols and Methods
Protocols
There are many different protocols available, but most widely used and accepted ones are:
REST
Representational State Transfer (REST) is a web architecture concept, which represents the current state of the requested resource. Client or requesting entity makes a logical request with the required data for a specific resource to the server; the server then responds with the current state of the resource without keeping or storing any information of the request.
REST follows these rules strictly
- Client-Server architecture
- Statelessness
- Cacheability
- Code on demand
- Layered system
- Uniform interface
Descriptions about these constraints can be referred here.
SOAP
Simple Object Access Protocol (SOAP) is a messaging protocol for web services. It uses XML to handle the request and response. SOAP is a neutral and extensible protocol available for any programming language and other protocols such as HTTP, SMTP etc.
Methods
Available methods for API testing are:
- GET
Most common and simple method which is to retrieve data from the server. - POST
This method is to create a new resource in the system. - PUT
This method is to update an existing resource. It requires that the entire resource data should be sent as a request body irrespective of the fields being updated. - PATCH
This method is also to update an existing resource with an exception that it does not require entire resource data in request body, only the fields which need to be updated. - DELETE
This method is used to delete an existing resource. DELETE is idempotent in nature meaning the result is same even if the same call is being made multiple times.
There are other methods available, but the ones mentioned above are the most used.
API Testing Challenges
Psychology
The biggest challenge in API testing is the psychology of the people who have not yet done it or just started to do it. Making a shift from testing UI based components to API creates a psychological fear that it is too technical in nature. Maybe because it doesn’t give the comfort of an interacting GUI and things happen at the back end.
All it requires is a basic conceptual knowledge of the client-server architecture. Web services functioning and a very good understanding of the system under test.
Documentation
Most of the time, documentation for the APIs under test is either unavailable or not exhaustive. It fails to provide the relevant and required information to the tester. This leads to a lesser confidence in the tester even if the test coverage is fairly good.
Untouched Server Side
Things are happening at the backend and the tester is relying only on the response data. What happened and why it happened is not clear or not seen at least. Imagine having server logs where the tester can see the action happening and build confidence just by knowing what happens when she makes a simple API call.
Too many tools to choose from
The market is flooded with myriad API testing tools. It is not easy to find out the best suited tool for your context. POSTMAN is one tool which is proven to handle almost everything. Better to go with it than experimenting with others.
Features of API testing tools
Must have features
- Option to select the verbs for the APIUT
- Option to provide headers
- Option to provide query parameters
- Option to provide request body (if applicable)
- Different environment for the same set of APIs
- Variable declaration for easy maintenance
- Option to collect related APIs in one set
- History of the used APIs
- Option to write pre-request script
- Example – Catch an object from an API and use the value in subsequent APIs as variables
- Authentication
- Basic
- Oauth
- Digest
- Selection of request body as JSON, Text or XML
- Support for RPC calls
Good to have features
- Sharable link for a predefined set of related APIs
- Compatible with other test tools
- Import of a new API from raw code
- Access to the request body from a file
- Writes tests
- Example – Write tests to assert some logic, these tests can be used to ensure no failures happen with the integration of other APIs. If there are changes which affects the written tests, tests should be updated accordingly.
- APIs handle a particular task as it is
- Example – APIs are handling exceptions for data related issues
- Auto generated reports (via email) in case of test success/failure
- History of last ten (whatever config is possible) tests and results
- Run related and integrated API under test in one go
- Permission based access for a project/organisation
- Example – Admin will have all the API access, like deleting a resource or creating a new one requires additional grant access
- Option to have global search
- An API can be searched via its name or path
- Option to fetch the newly done changes for the tool
- Support for RPC calls, sooner grpc is gonna be industry accepted thing
This article was developed by Satyam Dixit, Testing Delivery Manager at Qapitol QA.
Write to [email protected] for API testing services and automation solutions.