Runscope API Monitoring    Learn More →

Posts filtered by tag: collaboration

The Next Level in Collaboration: Share API Test Results

By Darrel Miller on .

We’ve talked before about the ability to share HTTP requests with team members and other people outside of your organization. This feature makes communicating about HTTP requests much easier than sending screenshots in emails or trying to describe HTTP header values over the phone. However, sometimes a single request doesn’t tell the whole story. Runscope is built to make collaboration a breeze, and now you can share entire Runscope test results with anyone with our new feature, shareable API test results.

A Link To The Big Picture

Runscope allows you to create a set of HTTP requests that exercise a particular API use case and assert that everything is working as expected. When a test fails, there is a problem to be solved that may require the input of several people. While developers on your team with a Runscope account can already see your tests and results, there may be developers, QA engineers or partners who need to be involved but do not have access to your Runscope dashboard. Being able to share test results containing details of each request and response by simply grabbing a single URL  saves valuable time when trying to communicate about and solve the problem.  

Developers on your team with a Runscope account can already see your tests and results, but what if you need to show the test to developers or QA people on other teams or even in another company? Creating a shareable test result is as easy as toggling the shareable flag at the upper right. By making a test result shareable, you are giving people a read-only view of your test results. This flag can be turned off at any time.

Sharing The Love

Chances are, if you are reading our blog, you’re already a Runscope user and you may have already seen this feature on the dashboard or seen the Changelog email announcing it. What you may not realize is there is another sneaky way you can use this feature to help improve your business.  

We regularly hear from customers who understand the value of using Runscope to test APIs and wish that other teams in their company were doing the same. By sharing test result URLs with other employees in your company, it may be just the thing you need to demonstrate the value of API monitoring. So why not go ahead and share with a coworker who you think could benefit from testing their APIs. 

Categories: howto, product, debugging

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®