When testing an integration with third party APIs it’s easy for tests to slow down and you might even start running into rate limits. The solution here is to use a gem like VCR (https://github.com/vcr/vcr) to cache the result of the API calls and replay them for subsequent tests.
This is a good approach and speeds up your tests, but leaves you with a possibly stale interface. How do you know when future API changes break your integration?
Today we’ll be looking at the methods we use for testing the Pivotal Tracker API integration at QAtab with a focus on making it easy to re-test against the actual API when necessary.
VCR Setup
I’m not going to cover VCR setup as there are many other resources online that instruct you in it. I will however strongly recommend that you configure VCR to filter sensitive data:
[gist id=6436901]
Here, we’re using the /spec/vcr directory to store our “tapes” and preventing any of our secret Pivotal details (which aren’t in version control) from being leaked.
VCR Organization
Rather than setting up a tag to automatically apply VCR in lots of places, I use many discrete VCR.use_cassette tags. This gives us lots of individual “tapes” and makes it easier to run individual test blocks against the live API.
[gist id=6436974]
Now, if you want to just run one test block against the live API, you can simply delete (or rename) the “tape” file and re-run your tests.
Regularly Testing Against the Live API
With this setup, running tests against the live API is easy. I recommend that every couple weeks, you simply back up the “tapes” from your last run against the live API and run your specs again:
[gist id=6437056]
If everything passes, you’re good-to-go, just delete your backup and keep on with development. If anything fails, you now have a clear record of the API requests and responses from a successful call that you can compare with the failed call to see what changed and how you can fix your code.
If there is lots of red, you might want to just put your backed up “tapes” back in place and start renaming them one-by-one to make the fixing cycle easier. Just keep in mind that code changes for these API changes may break your tests that passed previously.