I chose to use the 'elements' collection rather than choosing which elements to include (ie this supports inputs, textareas, buttons and anything else I didn't think of). It could be a bit simpler if we assume the element is a form. Even simpler if it's a fieldset (that has a disabled property). But I didn't want to limit it too much.
Unfortunately JS is quite ugly compared to Ruby. And 'prettier' made it uglier in my opinion.
Trying to cover it more comprehensively, and revealing we have a lot of behaviour to update.
Products and their variants should always get saved (or not saved) together. This is considered the most intuitive behaviour.
There's still duplication with the "variant has error" context, but I try to avoid nesting shared_examples, it starts to get ugly. Happy to discuss though.
Rails is registering a driver called `cuprite`. And when we did that as
well the driver got registered three times somehow. It looked like our
driver options were used in the end but just to clarify I gave it a
unique name.
This was inspired by:
* https://github.com/ViewComponent/view_component/pull/1877
It suggests that it may avoid dead browser errors on CI. We'll see.
We now check if the shipping method changed before we actually select
it. Fix the related spec.The spec was wrong because order.select_shipping_method
fails silently. That means the shipping method wasn't getting
updated on the order, thus the test was passing.
from old bulk product screen. Hmm I just realised we're deleting that screen soon anyway.
But this helps clean up the spec before I refactor it further.
I though that once the shipping method was set it's available on the
order, but apparently it's not always the case. At least some of the
test scenario have order with no shipment, thus no shipping method set.
We need to recalculate the voucher adjustment(s) in the following
scenarii :
When a voucher as been added to the order and :
* Moving to the payment step from details step, to take into account
potential change in shipment fees. (this happen if we return to the
details step after reaching the summary step)
* Moving to the summary step from payment step, to take into account
payment fees
Testing for the absence of behaviour is useful when changing code to
assert that the change is successful but in the long term, it doesn't
add any value. If you don't have any reason to believe that the report
may delete parameters then we don't need to test for that.
I've noticed that it was necessary to include a reference to the order like 'order.adjustments << create(:adjustment, order:)' for the tests to pass
Updates test case description
