#yerayamenitiz_best-practices
kind joltBOT
👋 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/1219657700527313018
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
loud spade
Hi there 👋 your unit test should likely not directly hit the Stripe API. It could cause rate limiting issues depending on the volume and frequency of that
https://docs.stripe.com/rate-limits
If you need sample responses to allow your flows to continue, then stripe-mock sounds like the best solution, or you could mock your own responses.
dusky dust
We are not interested in hitting Stripe API and we are not doing so at the moment, even though we have everything covered by tests. However, we faced an issue last week where one of our colleagues sent a metadata attribute next to the api_key and the unit test was written according to this mistake so nothing alerted us that the request being made was wrong.
So we are not interested in hitting Stripe API but to know if there's a way to prevent us from making these mistakes.
Mainly wrong formatted requests mistakes.
In this case it was somthing like `Stripe::PaymentIntent.cancel(payment_intent_id, {}, { api_key: <>, metadata: { ... })
and this is wrong request becase payment intent cancel does not accept metadata attribute
is there any way to catch this without manual testing and without an external service?
loud spade
Not that comes to mind, unless you build your own internal service for doing that.
dusky dust
I understand, thanks for your help.
By the way, one last question
What is your recommended testing strategy?
In general, from unit, integration and E2E testing
loud spade
That's a very vague question, can you be a bit more specific?
dusky dust
Well, I can tell you how we are doing it and if you think we are lacking something or doing something wrong. We are using Stripe sandbox environment for E2E testing, tests that run on our CI/CD pipeline before reaching production and for unit testing we basically don't do any real api request, we mock them all.
loud spade
That sounds fine if you aren't actually hitting our API. CI/CD pipeline checks can happen very frequently, so real requests (even in testmode) hitting our service could lead to rate limiting concerns.