API testing is easier said than done. When trying to do API testing we often find ourselves in the land of “what-ifs”—what if the third-party services we rely on are down? What if the APIs we need are still under construction? The solution, a Mock API. While this is a powerful approach, to unleash its full potential it is important to implement it correctly. That’s where Katalon steps in. 

In this comprehensive guide, we provide you with the steps to help you master API Mocking in Katalon. From getting your own server started with the ‘createAPIMockSession’ keyword to writing custom-tailored responses via ‘apiMockRule’. Read on to learn more about how Katalon can help you with this journey.

What is a Mock API?

A Mock API or Mock imitates a real-world API by providing realistic responses to matching requests. They can be made to run on your local machine or on a network machine or on the public internet. 

Responses from Mocks are mostly static and can be dynamic depending on the scenario. 

Why do we need Mock API?

Most web applications or standalone middleware applications have dependencies with external APIs when integrating third-party services. Sometimes they may be unavailable while development is in progress. Mock APIs are useful when you have external dependencies or APIs that are under development because they allow you to simulate responses until the external/development API is live. This allows QA teams to shift left and prepare and run test automation early in the development life cycle.

In addition, sometimes, you may require an API to be available for consumer testing or demos before you commit to developing it. 

How Katalon uses Mock APIs?

All it requires is a Katalon Studio plugin which allows you to mock your APIs and help you significantly left shift. There are three main keywords that allow you to mock APIs:

createAPIMockSession – This keyword starts the Mock server with all the rules hosted in it before the start of your tests/suites with the Mock.

It will create an API Mock on the specified host/domain and port via arguments. Below are the arguments and their respective conditions.
 

host – Optional – Specify the host/domain as string. Usually localhost, IP address of the host, or domain names. Default value is "localhost".

httpPort – Optional – Specify the port your API Mock will listen to. The default value is 8080.

httpsPort – Optional – Specify the https port your API Mock will listen to. The default value is 443.
 

Here are some examples: createAPIMockServer("localhost", 8080); createAPIMockServer("127.0.0.1", 443); and createAPIMockServer("localhost", 8080, 443).

apiMockRule – This keyword allows you to create specific API rules for which specific responses must be returned. For example, you could have a Mock API that sends responses for GET requests with specific URL path, message body, headers, authentication, or query parameters.

Below are the parameters that are used to create such rules (all these parameters are optional so a rule can be created without specifying any details, and in such case default values will be used):

httpMethod – Optional – parameter used to specify requests that match http methods GET, POST, PUT, and DELETE. If no method is specified, then a common response will be sent for any method. You may also create a condition by specifying “Any” if the response will be applicable for any type of transaction.

urlPath – Optional – if this parameter is not specified then the host provided during the create mock session will be used as URL/endpoint for the mock, or else specified URL path such as "/getNames" or "/deleteCity" will append to the host to form the URL/endpoint.

basicAuthUsername – Optional – do not specify if you don't have basic auth for the request.

basicAuthPassword – Optional – do not specify if you don't have basic auth for the request.

requestQueryParams – Optional – the URL query parameter condition that will be part of the request URL.

requestHeaders - Optional – the header conditions for the request.

requestBody – Optional – this is the body of the request as regex string. This is a pattern that will be matched.

requestCookies – Optional – cookie conditions on the request to send response.

responseStatus – Optional – the response status code that will be sent back to the client.

responseHeaders – Optional – response headers to be sent.

responseBody – Optional – response body that must be sent for the request condition specified above.

stopAPIMockSession – This keyword stops the Mock server that was started earlier at the end of your test run.

Below are the steps to get started with API Mocking:

Step 1

Download the latest Mock API jar version from the Katalon Store

Step 2

Place the Mock API jar into the plugins folder of the Katalon Studio project and then restart Katalon Studio. You should see the jar file in your plugins folder after restarting Katalon Studio. Also, on the Event Log tab you should be able to see the API plugin loading successfully.

You are now ready to use Mock APIs.

Step 3

Create a Katalon Studio Test Case for the API under test.

Step 4

Use Add to add Custom Keyword ‘createAPIMockSession’ using parameters for host, port, and httpsPort. You can also leave these arguments blank so default arguments for the same will be picked up.

Step 5

Now you can add multiple API Mock rules, as shown below.

Step 6

Create an API to meet the above Mock rule in the Object Repository. (You may also create verification rules for the API optionally.)

Step 7

Call the API created above from the API Test Case (shown below) and then add the final keyword ‘stopAPIMockSession’.

Step 8

Run the Test Case which should produce results like below:

Wrapping up!

Serving as an indispensable platform for developers and QA teams alike, Katalon Platform facilitates API Mocking. These features allow for a high degree of customization and flexibility, thereby providing a conducive environment for early-stage testing and seamless integration. The capabilities of Katalon Studio undoubtedly simplify the otherwise intricate process of API Mocking, thus accelerating the development life cycle and enhancing software quality. 

We hope you enjoyed this guide, stay tuned for more!