Testing Service Integrations with Bash and cURL

January 6, 2011 Evan Farrar

One of the most important parts of testing a system is “finding a seam”. Testing a whole system can be a foolhardy and unproductive first step. Find your seam, and begin spreading tests in each direction from it. External services almost always present us with an excellent and obvious seam. I was inspired to take testing my services more seriously after talking to pivots Jeff and Rachel about their recent work testing and developing Facebook integration for a client, and also after hearing from Paul Dix and reading his Rails Services book. Based on the words of Jeff, Rachel and Paul, I’ve drawn up the following strategy for testing services:

  1. Test at the point of integration downwards, that the live service returns what you expect for various inputs.
  2. Using the same tests to drive your development, write a fake-out of the service that passes the same tests.
  3. Then use the faked out service as you test upwards, that functionality in your app can utilize the features of the service.
  4. Once you’re ready to integrate, write a very high level smoke test that can pass against both the real service and the fake service.

After some analysis with our client and their resident WordPress expert, we determined we’d need to create users in WordPress when they sign up for rails, and update those users later when they change their information. We knew we’d prefer to use a simple HTTP REST API with a /users resource we could handle the C and U in CRUD. We’d also like to help the developer test drive his API, without having to learn much about Ruby. We chose to write some simple smoke tests in the most pervasive scripting language in world, Bash [1]. Luckily, Bash has an awesome standard distribution, usually including one of the best http wrappers ever written, cURL. So we began with the following script:

#!/usr/env bash
RESULT=`curl -ipost -s http://testsite.boonewebdev.com/api/users -pname=Evan+Farrar -pid=12`
if [[ $RESULT =~ 'evan-farrar' ]]
  echo "Test Create: Success. Got: $result"
  echo "Test Create: Failure. Got: $result"

There it was in a few lines of Bash: a failing test. The WordPress developer used our suite of tests, ran them as he refactored, extended our script and corrected it where we had made incorrect assumptions about his service. As we worked with him, it was much easier to simply run the test to see what had changed or what was failing than to try to communicate the subtle differences by email. Of course, once I first saw the script I went a little overboard with Bash hackery; I’ll have to save my resulting Bash unit testing framework for another blab…

[1] This statement is wholly unfounded and without research. I didn’t even ask my friend Google if this was true.

About the Author


Embedding Mongoid documents and data migrations
Embedding Mongoid documents and data migrations

When first starting out with mongodb, it's easy to make the wrong decision on whether to embed a document o...

New in Pivotal Tracker: Bugzilla integration, and more
New in Pivotal Tracker: Bugzilla integration, and more

Happy New Year! Pivotal Tracker has some updates for the new year: we've added a built-in integration with...


Subscribe to our Newsletter

Thank you!
Error - something went wrong!