Hacker News Reader

Comment by mootothemax | Hacker News Reader

Always fun when you're developing against an API, and then have to perform a frantic investigation to work out if your latest code change broke everything... or it's just the API endpoint itself.

View on HN

In ruby, at least, there are some good tools to automate this for you. Using, say, vcr, you can automatically "record" your API calls (into "cassettes") as your tests run; these data are then used when you run your unit tests subsequently. When you plan to integrate/push, simply delete the "cassettes" and run your tests again. That way, any API changes are picked up prior to integration.

I have a suite here that takes about 3 minutes to run from scratch, but just over 1 second as unit tests.

I had this problem years ago against the Twitter API. It took a shot of rum and a cigarette before I figured it out. And I'm not a smoker.

Unit test ( as already mentioned) and build up static json/xml/whatever files to run your code against so that you can integration test your stuff without integration testing the 3rd party stuff.

And hope your static files still match the API behavior when your done...

At some point you end up outside of the scope of testing, but you can build bootstraps to make sure that your mocks match whatever they are mocking.

Obviously, this does you no good when something like an API service goes down, but that's issue is irrelevant to the question that was posed. Having some static file to test against whether it is accurate or not will instantly tell you whether it is your code or the third party that is breaking.

That's actually a completely valid test to run: what happens when the API's results change on you? You should test that.

This is what unit testing is for

Reply on news.ycombinator.com