I’ve recently had a discussion about how I would go about testing code that makes calls to a remote third party API. It seems my way of thinking isn’t the same as most others. So I figured I would write out my thoughts and explanation behind why I would go for this route.
So first I want to explain other peoples thought patterns seem to be. It goes like:
The idea behind this is to make sure your code still works with the API such as it hasn’t changed with the functional test. While allowing yourself to just test your code on the unit level. Overall it gets the job done, I just think it’s slightly flawed.
So here is my plan of action:
The idea here is again we allow unit testing by wrapping and mocking. Then with the integration tests we ensure all the code within our application, even 3rd party code all integrate together and that everything goes well when the API returns what we expect. Then we smoke test the API to ensure it hasn’t changed and all works the way we expect it to.
Mocking and wrapping the API requesting code seems like a no brainer that everyone agrees with. We want to own the code we’re testing on a unit level. While decoupling ourselves to a certain extent from the third party API.
Mocking the API is where most people think I’m being a bit crazy. I think the fact there is extremely good tools out there to do this such as robohyrda say I’m not that crazy.
The reason I would go down this route is you’re decoupling your test suite from the third party API. When you couple your test suite a third party I’ve found you end up with the following issues.
So for these reasons I would want to keep away from hitting third party APIs in my test suite. But yes you still want to test the API works the way you expect, which is why you run a smoke test which isn’t an isn’t build failure. But something you run on a regular basis to say that you’re code will still work or if you need to change out the API requesting code.
If you’ve got another way of thinking I would really interested in hearing it.