API Testing Strategy

A critical part of API development is testing API services. Proper testing allows developers to produce a high-quality product to their clients. Testing enables API developers to guarantee to their customers that the system works under different conditions as expected.

APIs fail to perform consistently, alter, or produce errors with new releases? The cause of such malfunctions is a lack of testing.

Strategies for Organizing API Testing

The Testing Quadrant

The Testing Quadrant helps arrange tests in the right time and order and not to lose resources. The Quadrant allows for combining technological and business tests.

Technology stands for the correct features. All the parts of the API should work properly and consistently in any situation.

Business testing is making sure the product has been developed according to the customers’ needs and goals.

• Quadrant 1: Unit and component tests
• Quadrant 2: Manual or automated exploratory and usability tests. Requirement refinement
• Quadrant 3: Functional and exploratory tests
• Quadrant 4: Security tests, SLA integrity, scalability tests

Quadrants 1 and 2 include tests that detect development issues. Quadrants 3 and 4 focus on the product and its possible defects.

The top quadrants 2 and 3 check if the API corresponds to users’ requirements. The bottom quadrants 1 and 4 contain technology tests, i.e., internal issues of the API.

When a team is developing an API, they apply tests from all four quadrants. For example, if a customer needs a system for selling event tickets that can handle high traffic, the testing should start from the fourth quadrant and focus on performance and scalability. Automated testing is preferable here, as it provides faster results.

The Testing Pyramid

Another strategy for arranging API testing is based on the Testing Pyramid.

Unit tests are cheaper and easier to conduct than end-to-end tests. Unit tests are the base of the Pyramid. They relate to the Quadrant 1 from the previous strategy. Unit tests include testing small separated parts of code. They check if each “brick” of the construction is solid and reliable.

Service tests are more complex and, therefore, slower than unit tests. They require higher maintenance costs due to their complexity. Service tests check the integration of several units or the API with other components and APIs, that is why they are also called integration tests. Service testing allows developers to verify if the API responds to requests, if the responses are as expected, and if the payloads are returned as expected. The tests are taken from the Quadrants 2 and 4.

End-to-end tests are the most complicated. They focus on testing the whole application from the start to the endpoint and includes interactions with databases, networks, and other systems. End-to-end tests demand many resources for preparation, creation and maintenance. They also run slower than unit or service tests. End-to-end testing allows developers to understand that the whole system is performing well with all the integrations. These tests are situated at the top of the Pyramid because they perform at low speed with high costs and their proportion should be much smaller in comparison with unit tests.

From the perspective of a project owner, end-to-end tests seem to be the most informative. They simulate the real process of interaction with an API and demonstrate tangible results if the system works.

However, unit tests should not be underestimated. They check the performance of smaller parts of the system and allow developers to catch errors in the early stages and fix them with minimum resources.

Testing the API Core: Unit Testing

The main characteristics of unit tests are their abundance, high speed, and low maintenance costs.

When testing separate parts of the API, developers feel confident that their “bricks” of the construction are correct and operate as expected. If we develop an API for booking doctors appointments, the “bricks” of the unit testing might be the following:

• Correct authentication of patients
• Showing relevant slots in doctors’ schedules
• Appointment confirmation and related updating of the schedules

Unit tests are self-contained, as they are run independently, do not rely on other tests or systems, and provide transparent results. If the test fails, it is easy to detect the reason and correct it.

Sometimes tests are written before the code. This style of development is known as Test Driven Development (TDD). This way, tests guide the development process. It allows developers to know what their code should result in beforehand and write it in a clean and well-structured manner. If the code is changed and the implementation breaks, tests quickly catch the errors.

An outside-in approach is a way to perform TDD. With this approach, developers ask questions about the expected functionality from the user’s perspective. They write high-level end-to-end tests to make sure the API brings users the results they wish. Then, they move inwards and create unit tests for individual modules and components. As a result, developers receive a bunch of unit tests that are necessary on the ground level of the Testing Pyramid. This approach saves developers time as they do not create unnecessary functionality.

Tuning Parts Together: Service/Integration Testing

While developing an API it is important to confirm responses that match expected results. Service testing verifies how the API operates and how it integrates with other systems.

Service tests are divided into two groups:

• Component tests for internal checks
• Integration tests for checking external connections with databases, other modules, and services

Component testing is conducted to see if the API returns correct responses from inbound requests. Tests from Quadrant 1 verify if all the parts of the API work together. Automated tests from Quadrant 2 validate the right responses from the API, including rejecting unauthorized requests.

For example, to test the authentication component of the API that books doctors’ appointments the following endpoint should be tested:

• When sending an unauthorized request, the response should return an error of 401 (Unauthorized)
• When an authenticated user sends a booking request, a successful response of 200 (OK) is sent

Integration testing allows developers to verify the connections between the modules and external dependencies. However, it is not practical to set up the whole external system for this test. That is why only the communication with external dependencies is checked. Thus, bringing the whole database of authorized patients to check its dependency with the booking API would become an end-to-end test, not an integration.

Contract testing allows conducting integration testing while building an API. Tested interactions save developers’ time and guarantee compatibility with external services. To put it simply, the contract is an agreement that describes the rules of interaction between two entities. For example, when a patient books a doctor’s appointment, the contract specifies how the booking API interacts with the authentication service or patient database. Developers use contract testing to verify whether those interactions happen according to the rules set.

Testing for Vulnerabilities: Security Testing

Security testing stands in Quadrant 4 and is also a very important part of API development.

API specialists perform various types of security API tests such as Authentication & Authorization, Input Validation, Business Logic Flaws, Sensitive Data Exposure, Rate Limiting & Throttling (to prevent Brute force, DoS attacks), Transport Layer Security, Error Handling, Endpoint Security (only required HTTP methods are used), Dependency and Configuration, WebSocket & Real-Time API Testing.

For the booking API from our example they ensure that the whole doctor’s schedule or the information about other patients can’t be captured by malicious users or “attackers”.

Checking the Entire Functionality: End-to-End Testing

Finally, we have reached the top of the pyramid. We are using automated testing from the Quadrant 2 as a part of End-to-End execution. This approach verifies core cases and confirms that the systems work together and give correct responses.

To test an external API that should interact with multiple third parties it is not realistic to copy those systems and simulate how their UIs work. It would be a waste of time. That is why it is recommended to set test boundaries. For example, for our booking API, necessary services, such as authentication service, might be included in testing, while other external dependencies like messaging systems are excluded. This way the tests will target the most critical functions of the system and will not require additional time.

Another important point in organizing end-to-end testing is using realistic payloads. Large payloads may cause the APIs to break. Developers should know who their consumers are.

How Belitsoft Can Help?

Experienced software development companies like Belitsoft offer API development and testing services. Our experts in automated testing know how to maintain the balance between sufficient test coverage and confidence in a product.

Belitsoft offers the following API testing services:

• Functional Testing
• Validation Testing
• Load Testing
• Stress Testing
• Security Testing
• Reliability Testing
• Integration Testing
• End-to-End Testing
• Negative Testing
• Contract Testing
• Performance Testing
• Usability Testing

At Belitsoft, we understand the importance of sensitive data and use the best principles and tools to protect our clients at the development stage.

If you are looking for specialized API expertise, improved API quality, and a scalable API team, the Belitsoft software development company offers outsourced services to meet your needs. Contact us today to discuss your project requirements.