A Guide to Test 3rd Party APIs with Mock

Introduction

Testing third-party APIs is super important to make sure our apps work properly with external services. But testing them thoroughly can be tough because we can’t control these services, further, they can act unpredictably.

In this blog, we’ll talk about some smart ways to test third-party APIs better, like using mock techniques to create different situations and make sure our tests are strong and reliable.

If you are looking for solution to design mock without going through the hustle of writing and deploy a Mock API in few second then try Beeceptor , its my personal favourite :)

YouTube by Sidharth Shukla : https://www.youtube.com/channel/UCwuAfFzAIAKU9qVYBVHiT3A

Why We Need Mocking in Third Party API Testing:

Mocking is super important when we test third-party APIs because it helps us mimic how external services behave in a safe setup. With mocking, developers can create dummy responses from the API to imitate different situations like success, failures, timeouts, and dealing with big data. This way, we can run tests without relying on external services, making sure our results are consistent and predictable.

Scenarios for using mock in Third Party API

Let’s take some real-time examples to understand the scenarios and importance of mocking.

Scenario 1: Testing Error Handling

Your application interacts with a payment gateway API to process transactions. You need to test how your application handles error responses from the payment gateway, such as insufficient balance, expired tokens, or server errors.

• Why Mocking is Needed:

Despite having the test or sandbox environment setup, it is always super hard to test insufficient balance scenarios as the external providers do not care about giving test support for these. Mocking the payment gateway API allows you to simulate error responses and test your application’s error-handling logic without affecting real data or transactions.

Scenario 2: Testing Rate Limiting

In your application, you’ve connected with a weather forecast API to keep users updated on the weather. This API has set limits to maintain fairness and prevent misuse. Now, you’re tasked with checking how your application handles situations where the weather forecast API sends back rate-limited responses. This means you’ll need to simulate scenarios where the API reaches its limits and see how your application responds accordingly, ensuring a seamless user experience despite these limitations.

• Why Mocking is Needed:

Testing rate limiting with the live weather forecast API may lead to your application being temporarily blocked or restricted due to exceeding the rate limits. Mocking the weather forecast API allows you to simulate rate-limited responses and test how your application gracefully handles such scenarios, such as implementing retry logic or displaying informative messages to users.

Scenario 3: Testing Network Errors

Your application depends on a third-party geolocation API to fetch location data for user profiles. Now, it’s crucial to examine how your application reacts when confronted with network errors such as connection timeouts, DNS resolution failures, or server unavailability. This entails conducting rigorous testing to replicate these error conditions and assess your application’s resilience. By simulating these network error scenarios during testing, you can verify that your application handles them effectively, ensuring uninterrupted functionality for users even in the face of network challenges.

• Why Mocking is Needed:

Trying to test network errors with the actual geolocation API may not always work well because network conditions can change and give you unreliable test results. Instead, using a mock geolocation API lets you create and control network errors in a safe setup. This way, you can make sure your app handles these errors correctly, like showing error messages to users or trying requests again if they fail.

Scenario 4: Testing Large Data Responses

Your application interacts with a third-party product catalog API to retrieve product information for an e-commerce platform. You need to test how your application handles large data responses from the product catalog API, such as paginated responses or responses with a high number of products.

• Why Mocking is Needed:

Testing large data responses with the live product catalog API may impact performance and scalability, especially during automated tests or continuous integration pipelines. Mocking the product catalog API allows you to generate mock responses with large data sets and test how your application efficiently processes and displays the data, such as implementing pagination or optimising resource usage.

In each of these scenarios, mocking the third-party API is essential to simulate various conditions and behaviours without relying on live production environments. Mocking enables you to conduct thorough and controlled tests, ensuring that your application behaves as expected under different scenarios and conditions while minimising risks and dependencies on external services.

How to Create A MockServer in Just 5 Minutes?

Beeceptor is an easy and user-friendly mock API tool, requiring no-coding. It provides a hosted option, eliminating the need for any additional instrumentation, dependencies in your code or server setup. The API endpoint given by Beeceptor acts as a mock server for building routes/APIs responding to specific HTTP requests.

To set up a mock server with Beeceptor , follow these simple steps:

1. Open Beeceptor . Create a new endpoint by giving your project name.
2. Beeceptor will generate a subdomain for you to send requests to. Copy this URL and use it as the base URL in your API calls to ensure that requests are routed to Beeceptor’s subdomain. This subdomain will look like https://your-project.free.beeceptor.com .
3. Any requests made from your application to this subdomain will be automatically responded to with a 200 OK status code by Beeceptor .
4. Next, you define API routes or paths as mocking rules. By default, Beeceptor creates two mocking rules that align with the requirements of a To Do task listing application. These are GET and POST to /todos request paths.
5. You can define multiple rules, which can match based on request path and method, or any custom logic. The mocking rules are matched from top to bottom. If none of the rules match, your application will receive a 200 OK response from Beeceptor.

Copy this subdomain to your code and Beeceptor is smart enough to accept all HTTP requests on all the relative paths, and respond with either 200 OK or a response of your choice.

Start sending requests from your application. You can view these requests on the Beeceptor dashboard.

Conclusion:

Testing third-party APIs is a crucial step in ensuring the seamless operation of our software. Mocking techniques play a pivotal role in this process by allowing us to simulate various scenarios in which our applications interact with external services. Through mocking, we can replicate scenarios like failures, timeouts, and handling large data responses.

Arrange 1:1 call for help in career for AutomationTesting & SDET : https://lnkd.in/dF5ADMiU

^^^^^^^^^^^^

?? Hands-on learning experience in API,UI,Mobile automation, DevOps, Gen AI with realistic examples, consider a one-on-one guided session on end-to-end automation & SDET training covering topics: (API ( Postman / RestAssured)+ UI(Selenium)+ Mobile(Appium)+ DevOps(Jenkins,GIT,Docker)+ Generative AI for Testing+ DoubtSessions/MockInterviews with Sidharth Shukla) : https://lnkd.in/giCxnJJ7

^^^^^^^^^^^^

?? Generative AI for Software Testing: https://lnkd.in/gBjxYAPN

^^^^^^^^^^^^

?? Complete Interview Q&A Package to crack interviews for Automation Testing and SDET: https://lnkd.in/gJrBGExe

^^^^^^^^^^^^