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
Some important logic happens after the order transition from one state
to another. In particular, voucher are recalculated. To fix any
inconsistency, we make sure the order is the state matching the checkout
step we are on.
To be sure that every stimulus controllers attached to the DOM that is replaced is will connected.
What I saw is that when using `morph`, the stimulus controller (specially `tooltip_controller`) were not attached to the DOM (and not disconnected as well) that triggered some errors in the console.
Adds test case for payment capture thanks to @filipefurtad0
The feature toggle will determine which bulk products screen shows. An additional products_old path is also temporarily added for easy reference.
Later, when the old screen is full removed, we'll probably rename the _v3 classes to tidy up.
The report doesn't seem to sort. So the specs don't expect that either
now. These specs were flaky before, depending on the random order in the
database query result.
