CI/CD Integration

In some cases, you may want to trigger the execution of your tests remotely. For instance, if you want to integrate your RapidAPI tests into your CI/CD workflow, you need to trigger your tests execution from within your CI/CD platform. The easiest way to do this is by using the test trigger webhook.

Where can I find my test trigger webhook?

  • Navigate to the Settings page of the test that you want to remotely trigger
  • Scroll to the CI/CD Integration section on your Settings page. This section will help you determine the URL that you will use to trigger your test. Start by selecting the location + environment that you want your triggered test to run in, and the URL will dynamically include the correct location + environment details.
  • Make a request to the URL (either GET or POST works), and you will see that the test will be queued for execution.

Interpreting the trigger response

When you make the request to trigger the test execution through the webhook, you will get a few things in the response. Some details below.

  • success. This indicates whether or not the test was successfully triggered. Please keep in mind that this is not the indicator of whether or not the test itself succeeded.
  • reportUrl. Clicking this URL will take you to a test execution report on the UI. You will need to be logged in to see it.
  • executionId. Each test execution comes with its own execution ID.
  • statusUrl. Make a GET request to this URL to find out whether your test was successful. You will get a response similar to below.

Environment variable override

You can define + use environment variables in RapidAPI Testing. Environment variables make it easier to store data that is commonly used across multiple tests, as well as enable you to leverage one test definition in multiple environments. Simply define environment variables once, and then use those variables from within your tests. Check out this help document to better understand how to utilize environment variables.

One powerful functionality of our trigger webhook is that it allows you to override the values of the environment variables on a per execution basis. This enables you to be data-driven on your test executions by dynamically driving these values on each execution.

Let’s go through an example.

First, we need to define a test with environment variables in it. In the example below, I have two variables in my test.

  • The first one is the payload of the POST request
  • The second one is the {{status}} as the value of my assert equal.

Now, let’s override the values of payload and status when we run this test through the trigger webhook. We will do that by making a POST request to the trigger webhook, and specifying the overrides in the payload. Remember, we need to do this through a POST request (and not GET request) because we need to include a payload with the overrides information.

For the above test, here is what our payload will look like.

  "baseContext": {
    "payload": "{\"name\": \"Pen\", \"price\": 20, \"manufacturer\": \"Pilot\"}",
    "status": "200"

The payload takes one object called baseContext. In the baseContext object, you should include all the overrides as key-value pairs, the key being the environment variable name, and the value being the environment variable value.

From here, we can simply make the POST request with the appropriate headers and payload above, and the tests will be executed with the overrides applied.