Testing StripePaymentGateway for new Charges

[Lloople]

Hi Adam,

First of all, sorry if this is a silly question or has been already answered and can't find it.

I'm watching now the video where you're refactoring both StripePaymentGateway and FakePaymentGateway tests to be identical code inside.

I'm curious about the way you test carges in Stripe Payment Gateway. I mean, for me it looks like a bug to look for new charges made after the last charge the test found on set up.

What I'm trying to say is that someone can make new charges while you're doing this one, and that will give you 2 charges, for example:

• Person A starts the payment process
• Person A gathers the last charge (1)
• Person B starts the payment process with a better connection than Person A
• Person B gathers the last charge (1)
• Person B finish the payment creating a charge (2)
• Person B checks for new charges made after charge (1) and get charge (2)
• Person A finish the payment creating a charge (3)
• Person A checks for new charges made after charge(1) and get charges (2) and (3)

I think it will be better if we collect some Id in Stripe response after creating the Charge or something to know how much the client will be charged.

Sorry for bad english.

Thank you for your time

[drbyte]

What I'm trying to say is that someone can make new charges while you're doing this one, and that will give you 2 charges

Hi @Lloople, These tests use the "Test Account Credentials" for Stripe, so they are testing in a "sandbox". The "live" account area is not affected, and tests know nothing about "live" transactions. The assumption is that "only you" (or your CI server) will be using the sandbox. Thus there will be no new charges conflicting with your tests. The setup for using "test keys" for Stripe credentials (so all tests are run in a safe Testing Area, unaffected by Live transactions) was covered in Lesson 53, called "Generating a Valid Payment Token".

[adamwathan]

Hey @Lloople! @drbyte beat me to it; I agree with everything he's said. You could make the same arguments about tests that hit a database; if you try to save a record and assert there's now one record in the DB when there were zero before, someone else could also be saving stuff on the same database connection. Not a real problem in my experience; there's just an assumption that you are the only person interacting with the data store you're testing against.

In addition, we once had a detailed conversation about a very similar topic a while back, but it's sort of hidden/buried in a commit conversation. Here's the link:

https://github.com/nothingworksinc/ticketbeast/commit/3acda1137250217ccca176cf852f606e4b2940aa#commitcomment-22573718

Hope that helps!

[adam1010]

You can update your phpunit.xml file to use a different database when running unit tests. That way you don't wipe your testing database every time you run your test suite (and never have to worry about collisions).

I use an in-memory sqlite db for testing (for speed) but a full mysql database works too:

... ....

[Lloople]

Thanks for the replies.

I think the problem here is that I thought the code newCharges and lastCharge will be used in production but it will not. 😄

Thank your for the time of all of you.