Closed lutostag closed 6 years ago
CI is currently failing because I encrypted my tokens for my fork at lutostag/stripe-rs
it passes here https://travis-ci.org/lutostag/stripe-rs/builds/445327910
Just the encrypted env variables need to change. These can be updated by running:
$ travis encrypt STRIPE_CLIENT_ID=ca_ABC -xa
$ travis encrypt STRIPE_SK=sk_test_XYZ -a
$ travis encrypt STRIPE_ACCOUNT=acct_RST -a
But also as travis doesn't like these variables being shared in PRs, it won't work automatically until merged :man_shrugging:
I could also leave the tests as ignore for now and can merge them at a later time if that is more convenient.
Lets continue to #[ignore]
the tests for now, rather than "encrypting" a real account's sk_test_whatever
I'm looking at the other stripe client libraries for how they test things, and it looks like they test against a "stripe mock" rather than the real stripe API, e.g.:
Just sent a query out to one of the Stripe developers asking what their recommendation is for that, so that we can begin testing the right way in this crate
/library
.
Got confirmation that using stripe-mock is the recommended way to write tests; I've separately opened https://github.com/wyyerd/stripe-rs/issues/18 as an issue to address that.
@kestred thanks for doing the research on the proper way to test it all -- stripe-mock does seem like the better solution.
I removed the travis encrypted environment variables and marked the tests as ignore. Let me know if you see anything else that needs changes, more than happy to fix it up.
Thanks!
In order to use Stripe Connect to interact
with
(or as) another account, two headers must be specified, bothStripe-Account
andClient-ID
. This fixes the account to use both as required.Also automated the
stripe/tests/example.rs
to use environment variables and set the necessary ones for travis following documentation available at https://docs.travis-ci.com/user/environment-variables/#defining-encrypted-variables-in-travisyml