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.
The current implementation of the FDC is not adhering to the DFC
standard. The difference is added in this compatibility layer.
This should be temporary code. The FDC dev team should change their API
in their next development cycle.
