I work with a lot of APIs and I really appreciate good tools. Lately I’ve been really enjoying using Runscope for testing and monitoring my APIs so I thought I’d share how I work with this tool, which has a great one-person free tier *and* the ability to import/export tests so if you need to work with a team with just the free tier (the examples here are from an open source project which is an obvious use case where it’s hard to fund tools), it’s clunky but doable. The idea here is just to show you around how to create your own API tests with Runscope (and also to write down what I did so I can point both my future self and others at this!)

Create A Bucket

First up, create a “bucket” … I’d call this a “test suite” in any other setting. It’s just a place to keep things really but it has some really handy features:

• You can set up variables (such as a base_url) in the bucket which are then used by all your tests. This makes it trivial to make changes and run the tests again, for example against another platform
• You can also get your tests to use the bucket settings for which locations to run from and again, this makes it easy to change
• Once you’ve written some tests, you can trigger all the tests in a bucket by using a specific URL

Create A Test

I’m just creating a simple test, which points at https://test.api.joind.in and makes sure that there’s a “Hot Events” URL listed, and that calling it returns sensible data.

This just shows that I have the Bucket-wide settings selected, and a test with two steps – first to get the main API page, and then to get the Hot Events page.

The {{base_url}} is set in the bucket-wide settings, which are selected in the top-right hand side of the test (this took me ages to find the first time), and I use it to define what to call:

As well as setting some “assertions” that your response must fulfil (more on those in a moment), you can grab “variables” from one response to use in the next request. In this example I want to get the hot-events property so I can then call it (this is hypermedia; the URL might change).

With that URL captured, my next test simply calls it. Both steps have some assertions that the responses must be compliant with – here are the ones I have added to check the response of the second step:

If any of these assertions fail, the test will be marked as failed. When working on either capturing variables or writing assertions, look out for the “Last Response Data” accordion piece, it’s super-helpful to be able to see what came back last time!

Running the Tests

I can run tests individually (look for the “Save and Run” buttons at the top of the edit test screen) and the history of results are displayed in the sidebar (as you can see in my screenshots, I was still working on getting this test passing until shortly before I took the screenshot!), You can also run tests all together and with different settings – that’s a blog post for another day perhaps.

Runscope can run your tests on a schedule, and be set up with alerts for how to let you know if something fails. In addition to the pass/fail data, it also stores information about how long each test takes, which can be really helpful if you’re suddenly seeing timeouts to be able to realise that your API got slower two deploys ago or something.