#peter-belbin_frontend-testing
sudden jacinthBOT
đ 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/1270120857078988802
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
pure mist
Hi there
sudden grotto
hey.
pure mist
I have a storybook for some test scenarios
As in you have some automated testing for client-side behavior?
When capturing screenshots, sometimes, a requested URL never resolves
Can you provide more context?
pure mist
No, I've never used it before
sudden grotto
it's a tool where it will mock up website aspects scenario at a time and present them via a web interface
pure mist
We generally don't recommend running UI tests against Elements. Instead, Elements bits should be mocked based on config and outcomes
sudden grotto
Well, put it this way, we have been using storybook for a long time, and until recently, it's been very good.
storycap is a tool that, given a storybook-produced website, will remote control (using puppeteer) an instance of Chromium browser, and allow you to take screenshots, which can be checked into version control, so that changes to the outcomes can be flagged for further investigation or confirmed as not having changed.
Until recently, this has been working great for us.
However, of late, I've been seeing that sometimes, specifically when it comes to Stripe iframe content, that sometimes, one of the requests that Stripe servers should be replying to is receiving no response at all. This, of course, gums up the works considerably.
The related question to this observation is: if we're now seeing this issue of not getting a response is happening on multiple engineer workstations (both in the office and remote) & google gcp-hosted continuous integration environments, is this something too that is sometimes impacting our customers?
Like I mentioned, this is able to be observed by me using a browser with the dev-tools open, and observing on the network activity tab, that sometimes a response is not being provided to requests to Stripe's systems.
pure mist
The related question to this observation is: if we're now seeing this issue of n...
Likely not but what action are you recreating here exactly?
sudden grotto
It's an iframe that points to Stripe that is accepting credit card details to capture payment details. It has an input field with the card number on the very left being able to be input, and on the right hand edge, input for the mm / yy and cvn code
pure mist
So the CardElement?
sudden grotto
I guess that's what it's called, yes.
In one case, for example, the request that failed to get a response back looks like https://js.stripe.com/v3/m-outer-[bunch of alpha numerics].html
pure mist
I'm not familiar enough with Storybook to recommend anything in particular. What exactly is the lack of a response causing in your tests?
Ultimately, we don't recommend client-side testing so there's not really anything I can do to help in this case
sudden grotto
Well, the testing is not trying to plug in any card details as far as I'm aware, so I think it's just rendering the iframe contents before any text would be supplied.
But, the Stripe servers not providing a response is definitely gumming up the works! storycap basically grinds to a halt!! As I say, this is a very recent phenomenon. Until now, eg: last 2 weeks, it's been no issue, but now, it's becomming a huge headache. But, perhaps the bigger concern is regarding customers.
Stripe doesn't really have a separate 'test' platform versus the 'real' platform, right?
I know we can use 'test' card numbers and such to do testing, but I think it's not a separate platform, right?
pure mist
There's a pair of test API keys you can use (your test mode secret key and your test mode publishable key) but that's it
sudden grotto
Right. So, aside from test API keys, it's the same platform as what everyone is using.
So, one of the concerns is that this is also affecting customers.
pure mist
You mentioned your testing scenario stops but what does this actually look like within the browser?
sudden grotto
Well, in a test I did in the browser, with multiple retries, and occasionally seeing the issue happening, I was noticing that sometimes the input area box was not visible.
This is just me using a browser and clicking reload multiple times. So this is much like what customers would be seeing.
pure mist
Do you have a link where I can try to reproduce this myself or is this still within your testing scenario?
sudden grotto
ummmmm, it's just running locally, so, not available for you to try, I think.
pure mist
I see
sudden grotto
Does the timeframe of the last couple of weeks or so line up with any changes to things on your side by chance?
May have been happening for a bit longer, in fact.
pure mist
That's hard to say. We constantly make changes to Stripe.js
sudden grotto
It's really odd that when it happens, there's just no response at all (as far as dev-tools is concerned).
pure mist
I don't think this is an accurate test of what a customer could experience
sudden grotto
everyone's entitled to their opinion, but, can you explain why you think that?
it would be very helpful to have your reasoning, so that I can provide it to the person I report to
pure mist
As long as you're using a valid publishable key to initialize Stripe.js and Elements, the CardElement should be displayed.
sudden grotto
Are the test API keys considered 'publishable'?
sudden grotto
hmmmmm. and if it starts with sk_ , I guess you're saying that's not publishable?
sudden grotto
ah, ok, so if I have a test API key, that consists of a 'secret' and 'publishable' key (similar to public/private key cryptography), is the publishable key something I statically know, or is it generated dynamically by the Stripe.js and not knowable beforehand?
pure mist
API keys are static and don't change unless manually rolled: https://docs.stripe.com/keys#rolling-keys
sudden grotto
ah. ok. I will look into your observation / assertion that if the publishable API key is configured correctly the card element should be responded to reliably and should present / render normally. Please confirm: I take it you are saying that it should work reliably regardless of whether it's a test or non-test key, if it's properly initialized with the publishable key - and it should not matter if that is a 'test' key or not?
pure mist
Correct
sudden grotto
ok. thank you. I will verify. It's the end of my work day here, so it will be tomorrow that I dig into that to establish what's happening on that front.
sudden jacinthBOT