What's your take on writing tests for third-party services or integrations?

twitter logo github logo ・1 min read

Let's say you have an application that uses Stripe.

Stripe gives you a dev environment- own API key, own dashboard, own data, all separated from your Stripe's live data.

Do you write tests that interact with this dev environment or do you mock the responses or something alike?

I work on an app that has many integration tests communicating with test/dev/sandbox environments, and they sometimes fail due to errors on their services, not on our own. Now we're discussing if should we mock the responses instead.

twitter logo DISCUSS (5)
markdown guide
 

I recently had the great displeasure of integrating with PayPal's sandbox environment. To put it mildly, the service had stability issues that disrupted the integration process. I actually ended up with so little faith in the results of testing with the sandbox that I reduced the item under test's cost to $1 and ran real tests against their production server manually to get some sense that their service would work reliably post-launch.

My solution to this situation? Damn if I know. Mocking wouldn't have helped - it would have just given me a false sense of security as it would have to assume the live service adhered to their documented API, which I found at least one mistake in during development. Also, PayPal can break their API any time they wanted for any reason, but I can't tell what constitutes a "break" vs a "change" in their API, so I may end up with false alarms that were just from them making innocent changes.

Having said that, if someone had a gun to my head and said, "Make a real suggestion" I would do 2 things:

  1. Mock the responses so at least your tests will run predictably
  2. Write live assertions against their API with alerts (email, SMS, chat hooks, whatever) for when there is any change in their API such that for a given request a response is returned that is not your expected mocked response.
 

Thanks for the story! Mocking seems the way for a predictable testing suite.

In relation to the live assertions, maybe I can still run the tests that interact with the sandbox environment in a separate test suite that is outside the golden path of deployments and, as you said, have some alert to check when things go south with the integration.

 

That would be my thought - two independent test suites.

 

The prevailing wisdom here is to record actual responses from the third party and use them to mock responses in your integration tests. You shouldn't be testing third party APIs in your integration tests.

You may want to separately ping the API with monitoring software to ensure it's up, but the wisdom is you trust the third party to act the way it says. If you can't trust them, you should have vetted the service better before choosing it.

 

Thanks for the advice! We already ping the service, but I thought it would be a good idea to also test the specific endpoint responses themselves.

I'll change the tests to mock the response instead and see how it goes

Classic DEV Post from Jun 15

Know Not Only Your Weaknesses, But Strengths as Well

Most people want to develop self-awareness. Whether we are managers, entrepreneurs, or aspiring software engineers, the more knowledge we have of our strength and weaknesses, the easier life becomes.

David Ojeda profile image
Software developer and Overwatch amateur.

Sore eyes?

dev.to now has dark mode.

Go to the "misc" section of your settings and select night theme ❀️