Runscope API Monitoring    Learn More →

Posts filtered by tag: environments

Using the Runscope API to Dynamically Update Environment Variables

By Neil Mansilla on .

Runscope API tests support variables, allowing you to pass one or more values between requests within a test. Variables are extremely helpful when you need to extract data from one request in your test and then apply or compare that value at another stage of your test. We sometimes refer to this as chaining requests. Variables can be declared before an API test run using Initial Variables (located in Environment settings), or you can create them dynamically after each request within your test. Runscope variables are limited to an individual test run, which means that they are reinitialized with each test run. 

There are many use cases for needing to persist variables, such as storing credentials like an access token in an initial variable. This makes it convenient for making authenticated API requests in your tests and...

Read More →

Categories: howto, product, testing

Running a single API test plan against multiple environments

By John Sheehan on .

UDPATE: This method is no longer required. We have added new features that enable you to seamlessly reuse the same API test across multiple environments. 

Every day we hear from Runscope customers who are looking to run the same Radar test against multiple environments. Sometimes it's "staging" and "production" environments, other times it's for a fleet of servers behind a load balancer that all serve the same API.

In this post I'll show you how to use a few of Radar's features in order to create a single test plan that can be applied to different environments.

Creating the Test Plan

Let's start by creating a simple test plan using the Runscope API. In this case we'll just hit a set of endpoints in our 'prod' environment directly:

This is a simple test that checks that our credentials are correct, creates a new bucket, then retrieves the newly-created bucket (the second request stores the new bucket key in a variable if you were curious).

You can see that all of the requests are hard-coded to use our production host name in the URL. We also have an "Authorization" header (not shown) with a access token that will only work in our production environment. To make this test work with our staging environment we need to start by abstracting out the environment-specific data into variables.

Using Initial Variables for Environment-specific Settings

I'll define two Initial Variables for our baseUrl and accessToken values, using the same values I previously hardcoded into the request editor.

I've included the the scheme in our baseUrl value since our staging environment uses plain http instead of https. I also left out the trailing slash since it makes tests easier to read later on when we use that variable.

With our initial variables defined, update the requests to use the variables:

When I run the test from the dashboard, it will use the values I've entered in the Initial Variable editor and dynamically insert them into the requests:

With our test plan defined, we can now use Trigger URLs to initiate test runs with custom sets of initial variables.

Dynamically Specifying Environment Variables with a Trigger URL

Trigger URLs let you kick off test runs from other tools that are part of your build or deploy process, like GitHub, Jenkins, Heroku and more. Every test has a unique Trigger URL that accepts a single GET or POST request to start a test run. These URLs also accept parameters to allow you to specify custom initial variables to use for a given test run.

For this test, I've put together a Trigger URL that sets the baseUrl and accessToken values to match those required by our staging environment. It looks like this:

Requesting that URL via curl or the browser will start a new test run with those values, overriding the default values and dynamically inserting them into the request data:

For our case, we make a request to the Trigger URL at the completion of a deploy for a service to any given environment. We can also run these tests against local or private endpoints using the Runscope Radar agent (in private beta, contact us to learn more).

Need help with your own API tests?

If you need help getting your API tests configured to run in multiple environments, drop us a note, we're standing by ready to help.

Categories: howto, product, testing

Everything is going to be 200 OK®