Stripe integration tests that actually hit the Stripe API #27

snowdriftimport commented 2017年07月09日 09:30:30 +02:00 (Migrated from gitlab.com)

Using our account's test key will allow us to really communicate with Stripe and get real responses (albeit with imaginary money). We should use this to write tests about our Stripe assumptions.

• Are we calculating the fee correctly?
• Do the API commands we use exist and respond as we expect them to?

We don't want to spam the crap out of Stripe's servers, so access to the test key (and the ability to run integration tests) will be limited.

Using our account's **test key** will allow us to really communicate with Stripe and get real responses (albeit with imaginary money). We should use this to write tests about our Stripe assumptions. * Are we calculating the fee correctly? * Do the API commands we use exist and respond as we expect them to? We don't want to spam the crap out of Stripe's servers, so access to the test key (and the ability to run integration tests) will be limited.

snowdriftimport commented 2017年07月10日 19:38:05 +02:00 (Migrated from gitlab.com)

What does an integration test look like? Perhaps we need 2 separate categories of tests:

1. Stripe API tests, e.g. check balance, make payment, check balance again, make sure it changed
2. Integration tests of the whole platform, e.g. get a project's balance, choose a random number of patrons with random attributes etc., run crowdmatch and makePayments simulating some amount of time, check balance again, compare to what the mechanism thinks the balance should now be according to our DB, and to a pure Haskell calculation of how much money is supposed to get paid, make sure all 3 give the same number

By Anatoly on 2017年07月10日T17:39:32 (imported from GitLab project)

What does an integration test look like? Perhaps we need 2 separate categories of tests: 1. Stripe API tests, e.g. check balance, make payment, check balance again, make sure it changed 2. Integration tests of the whole platform, e.g. get a project's balance, choose a random number of patrons with random attributes etc., run crowdmatch and makePayments simulating some amount of time, check balance again, compare to what the mechanism thinks the balance should now be according to our DB, and to a pure Haskell calculation of how much money is supposed to get paid, make sure all 3 give the same number *By Anatoly on 2017年07月10日T17:39:32 (imported from GitLab project)*

snowdriftimport commented 2017年07月12日 03:43:21 +02:00 (Migrated from gitlab.com)

I think that makes sense, yes.

By Bryan on 2017年07月12日T01:43:21 (imported from GitLab project)

I think that makes sense, yes. *By Bryan on 2017年07月12日T01:43:21 (imported from GitLab project)*

smichel17 commented 2021年07月08日 01:38:18 +02:00

marked this issue as related to #602

marked this issue as related to #602

smichel17 commented 2021年07月14日 16:40:14 +02:00

changed title from {-Need to implement -}Stripe integration tests that actually hit Stripe API to Stripe integration tests that actually hit {+the +}Stripe API

changed title from **{-Need to implement -}Stripe integration tests that actually hit Stripe API** to **Stripe integration tests that actually hit {+the +}Stripe API**