If I regenerate the VCR cassetes for
spec/lib/stripe/payment_intent_validator_spec.rb, I get a lot of errors
like this:
```
Stripe::CardError:
Sending credit card numbers directly to the Stripe API is generally
unsafe. We suggest you use test tokens that map to the test card you are
using, see https://stripe.com/docs/testing. To enable testing raw card
data APIs, see
https://support.stripe.com/questions/enabling-access-to-raw-card-data-apis.
```
It seems the sandbox environment associated to my developer API keys is
not allowed to send raw credit card data.
Instead of requesting Stripe support to enable that, or regenerate
cassettes with the API keys in Bitwarden, I figured we could migrate the
tests to not use raw credit card data.
Working within a shadow root of the web component isn't well supported
by Capybara and I needed to find some workarounds. It's not pretty but
it works (on my machine). *fingers crossed*
And demonstrate the use of puffing-billy browser proxy.
Billy can cache and record responses to browser requests. For that to
work we need to allow network connections and disable VCR. But instead I
found that the Billy proxy is just like any other Ruby backend code and
its connections can be recorded with VCR instead.
And instead of stubbing requests via Billy.proxy, we can use standard
Webmock `stub_request`. Now we use puffing-billy just to relay browser
requests via our Ruby app.
Not the best UX but the easiest next step to implement. Next we should:
* Include link in error message instead of redirecting straight there.
Otherwise users may feel disoriented.
* Provide a custom error message?
A test was failing locally because I have the OpenID client secret set
in my environment. And the dummy value was the same as another test key.
So it got replaced with the wrong value.
The new job class blends code from the BackorderJob and the
CompleteBackorderJob for the specific case of adjusting quantities after
an order has been cancelled.
I would like to write a more general class which can be used for any
order amendmends but this was the quickest solution to cater for
currently running pilots.
The class is moving to providing all data with several methods instead
of a data class containing the information. That should be more
flexible. Still some work to do.
Previous specs testing the live API assumed an order to be present or
not present. You needed to provide the right state before recording. I
condensed more into one test that completes the cycle and is repeatable,
assuming no order to start with.
