#tristanoneil_terminal-automated-testing

1 messages · Page 1 of 1 (latest)

teal chasmBOT
#

👋 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/1294324779645669469

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

undone saddle
#

The test in question passes the first run, so it does appear the issue lies with using recorded responses. I think in particular it's failing here:

    const paymentResult = await this.terminal.collectPaymentMethod(
      paymentIntent.clientSecret
    );

    const confirmResult = await this.terminal.processPayment(
      paymentResult.paymentIntent
    );
teal chasmBOT
deft sleet
#

Hi 👋

Can you explain what you mean by "recorded responses"

undone saddle
#

We're using the VCR gem to record responses from the Stripe API

deft sleet
#

Also what platform are you using to integrate terminal?

undone saddle
#

The JS SDK

#

so in the scenario of ^ paymentIntent would be a payment intent that has already been processed.

deft sleet
#

Are you trying to use a mocked Connection Token when you attemp to connect to the reader?

undone saddle
#

No it's not mocked but the token would have previously been used in other spec runs.

#

I get it's a bit odd processing payment for a payment intent that has been previously been processed ... I'm just wondering if there are suggestions for how best to handle a more real to life test.

deft sleet
#

It's not clear to me why you are doing any of these mocks at all. Is this using some automated testing suite?

undone saddle
#

Yes, this for automated testing.

deft sleet
#

Are you using an actual physical reader or our simulated reader?

undone saddle
#

simulated reader

#

The stripe-mock library suggestions this:

If you have more sophisticated needs, you should define your own mocks, use a playback testing tool like the VCR gem, or find a community library you trust. Be careful, though. Always test changes to your Stripe integration against testmode. Mock implementations of Stripe can never behave exactly at the Stripe API does, and might differ in nuanced (and potentially dangerous) ways.

#

given the suggestion of using VCR I would think generally there'd be a way to do this but 🤷

deft sleet
#

Unfortunately the stripe-mock library has been deprecated for quite some time. I don't think we have a specific set of best practices for automated testing of terminal integrations

#

But let's pause on that for a sec

#

You said the error gets thrown after the first round of testing succeeds?

undone saddle
#

Yes, that's because the first time it runs it's making actual requests/response to the Stripe API in test mode

#

but the second run it plays back those responses

#

or rather the second run and all subsequent runs

#

Ok so it appears the specific error is ""Request Failure {"message"=>"The Stripe Terminal ConnectionToken has already been redeemed. Please generate a new one using v1/terminal/connection_tokens.", "type"=>"invalid_request_error"}""

deft sleet
#

AFAIK the connection token is only valid for a single use. Once that connection occurs, it is considered consumed. Are you refreshing that token value?

#

Yup, bingo

undone saddle
#

We are not, because we don't want to make real HTTP requests in our automated test suite.

deft sleet
#

Unfortunately there isn't a way around that for connection tokens

undone saddle
#

Hmm ok, that'd be a great feature 😄 . In general, more cohesive support for automated testing with Stripe would be great. Anyway, thanks!

deft sleet
#

I'm happy to shed what 💡 I can 🙂