#tea-hanks_automated-testing
severe mesaBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1478081608685850828
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- tea-hanks_api, 4 hours ago, 19 messages
- tea-hanks_api, 3 days ago, 33 messages
vital citrus
Hello 👋
For automated testing with high volumes of API calls, we do recommend a mocking approach. In that case we suggest you use the Test/Sandbox API to determine the shape of the Stripe API responses but then mock those objects for any automated testing of your own integration.
For example, if you have an automated testing suite that relies on returning a Payment Intent when you generate one with the following payload
{
"amount": 1999,
"currency": "usd",
}
We recommend you make that API call manually, copy the JSON returned, and use that to mock future responses.
grizzled patrol
Interesting we are kind of doing something similar but instead of having a totally static response, we do have some logic in our mocks that updates some of the fields of our mocked responses
I guess what I am worrying about here is that if I don't test against the real API then I am not 100% sure if my mocks are up to date
vital citrus
Yeah that's fair. What we have recommended is that you have some periodic mock updating.
To test out an approach I wrote a basic mock service that just mapped specific API calls to hard-coded JSON payloads. But my service also had an update command where it actually made those API calls and overwrote my existing JSON with the responses. This was especially useful when fields were added or I upgrade API versions
But it is a pain to maintain, since you basically create a route for every single unique API call
grizzled patrol
Kind of in a similar painful situation
Well thanks for the discussion. I feel like there is no straight forward way. Seems like each approach has pros and cons and will offer different level of confidence
Will go over this info and think about what suits our needs the best
vital citrus
The main reason to avoid making direct API calls for each testing scenario is you don't want all your development work stopped due to rate limits. These are 25 rps in Test mode.
Depending on the number of API calls and tests, it might make sense to run a specific batch of tests validating Stripe responses from time to time and rely on your mocks for the rest of the time.