6 ms·

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

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.

zmoazeni 14y ago
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.
ckdarby 14y ago
This is what unit testing is for
DanielN 14y ago
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.
- Retric 14y ago
  And hope your static files still match the API behavior when your done...
  - DanielN 14y ago
    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.
  - timdorr 14y ago
    That's actually a completely valid test to run: what happens when the API's results change on you? You should test that.
auxbuss 14y ago
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.

6 ms·

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

by mootothemax 14y ago

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.

zmoazeni 14y ago
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.
ckdarby 14y ago
This is what unit testing is for
DanielN 14y ago
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.
- Retric 14y ago
  And hope your static files still match the API behavior when your done...
  - DanielN 14y ago
    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.
  - timdorr 14y ago
    That's actually a completely valid test to run: what happens when the API's results change on you? You should test that.
auxbuss 14y ago
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.