How to Test Code That Uses HTTP APIs Like Orchestrate

Originally posted on the Orchestrate Blog

March 13, 2014

Share +

When you decide you’re going to integrate a web-based API like Orchestrate into your application, writing tests can seem daunting, annoying or even impossible. But fear not! I’m going to share a really easy way to write API tests. By the end of this post, you should have a clear picture of how to test your application when using APIs like Orchestrate.

Hat tip to Myron Marston for a great addition to the Ruby (and programming) community, called VCR. Rather than trying to describe what VCR does in my own words, I’ve lifted what Myron says from the VCR’s README:

The moniker “VCR” is a fantastic metaphor for what the library actually does. It “records” by serializing (generally in YAML) the request and response of the HTTP interactions as the test suite exercises the application code. These recordings are known as “cassettes” and are usually called fixtures in your test suite. The fixtures are then used to mock the request and response of the HTTP or network libraries without actually sending anything over the wire.

The quick example below is in Python, but you can do this in many other languages:

Now for the feature presentation—Below, I will demonstrate the use of the Python port of VCR, VCR.py. For this example, I’ve chosen to write tests for a community-contributed Orchestrate client library written by Jeremy Brown called orchestrate-py. The client library is fairly new, and as Jeremy pointed out:

"This is early in it’s development and subject to change. Collaborators, suggestions and testers welcome.”

Keeping the API key in the code is OK in this instance because, with Orchestrate and many other services, it’s easy to destroy an API key and regenerate a new one. We’ll want to do that at the end once we publish our commits; then only the old, inactive key will be in the fixtures and tests.

Step 3 – Write Your Test

Here we’re just simply testing the ability to put a key and value into a collection in Orchestrate.

When I decorated the function, I didn't create the directory structure or the file name. VCR.py will auto-magically create this for us the next time we run the test suite. Based on our configuration of VCR.py in step 1, we are going to use the record mode “once”. This means we’ll let the HTTP library make a call once and write the output to our cassette file. There are other modes, discussed in VCR.py’s documentation.

Step 5 – Run and Record Your Test

This is straightforward enough. In our case, since we’re using py.test, all we do is:

py.test test_orchestrate.py

Once we’ve done this, we can see that the fixtures (aka “cassettes”) have been recorded and placed in: ./fixtures/vcr_cassettes/put_key_value.yaml. Feel free to explore it, since it is written in YAML it is pretty straightforward.

Note, the fixture has recorded the Basic Authentication headers. Since this is hard-coded into our fixture and we will check this into a repository, we will want to destroy our API key that we used for testing.

Step 6 – Run Your Test Again and Enjoy

Finally, if you run your test again, you’ll notice a marked performance gain in testing. This is because there isn’t any network traffic—VCR.py is handling those requests for us and using the fixtures we have defined.