RestAssured #4 - Introduction to API Testing

What is API Testing?

An API abstracts the application layer and provides the resource(s) for consumption by the client. APIs are the middle tier of an application and they deal with the back end, usually via an ORM (Object-Relational Mapping) or any other tool, or directly with the database and with the front end. The API acts as an agent between the back end and the front end. The API reads the data from the back end based on the user requirement/request and sends the response to the front end.

For APIs that do not have a front end, the owner of such an API provides a service-based model to their users, such as a payment gateway, and weather forecasting.

API testing is grey-box testing as testers require internal details of implementation as they need to test the APIs individually by understanding the technical aspect of the application logic inside the API.

API testing involves testing of middle tier before it is consumed by the consumer/front end. It may involve testing the individual component of the application or combining a few components to test a user workflow. API testing involves testing endpoints of the API based on the given contract.

  • The endpoint is defined in terms of the URI, such as /api/v1/products/{productId} or /api/v1/products.
  • The contract should be in the required format (JSON/XML) of the request, and it may or may not include the parameter(s) based on the request method.
  • Accessing an API requires a mechanism that allows us to perform various actions based on the requirement(s), which are called request methods.

Why test API?

  • The ROI on testing early in the software development process is much higher than testing at the end. Since API testing has larger code/functional coverage, the testing tends to be much more efficient compared to front-end testing.
  • It is faster to identify bugs at the individual API level because the complexity is lower and the possibility of finding bugs is higher compared to finding the bugs on the front-end level.
  • Testing only the front end is an error-prone process. Since the frequency of the changes on the front end tends to be much higher than on the back end/middle tier, the failure rate also tends to be higher.
  • As a result, it’s time-consuming to identify whether the bug is a back-end/API bug or a front-end bug.

Types of API Testing

  • Functional testing addresses the functional aspects of the API, such as returning a response as per the business requirements.
  • Performance testing addresses the response time under load. When multiple requests are made for the given API at the same point in time, the API should return the response in the allowed time limit as per the SLA definition agreed upon between the service provider and consumer.
  • Security testing addresses the unauthorized access of the API by gaining access to the session, parameter tampering, and so on. The API should not allow any anonymous/unauthorized users to gain access to the data via itself.
  • Noise testing addresses invalid or malfunctioning data in the request. The API should respond accordingly and on time. If the data is invalid, the API should respond with the proper error code/message.
  • Error code and message testing address incorrect input data and respond with the appropriate error code and message.
  • Scale testing is related to infrastructure, which is a DevOps routine job, but the API gets tested in this scenario as well. This is mostly the case in microservices architecture where a particular API is used more frequently. The API should be made scalable since the concurrent access shall be more frequent and the API should be made available all the time.
  • Compliance testing falls in the local jurisdiction where the API is being consumed. For example, if the API is asking for personal information (cell number, city of birth, etc.), then this information should be protected by the vendor, any attempt to get this information should not be allowed, and audit logs should be maintained.
  • CDCT (consumer-driven contract testing) means that the service provider always maintains the same request payload. This is critical for the business of the service provider. If the payload is changed, then the consumer request will start failing and it will be a loss to the business.

Advantage

  • Easy to automate
  • Faster at finding bugs
  • GUI independent
  • Maximum code path coverage

Reference - Learn API Testing: Norms, Practices, and Guidelines for Building Effective Test Automation (Book)

Did you find this article valuable?

Support SUBODH SINGH by becoming a sponsor. Any amount is appreciated!