Interaction with the variant autocomplete is not precise. The specs only
search for the product name, then click the first result that matches
the product name which they see.
This could have been the case because searching using the full variant
name does not match the variant. For example, searching "Some Product -
1kg" would not have results, while searching only "Some Product" (the
product name) would list "Some Product - 1kg".
Clicking the first match does not work in all scenarios.
This allows using a separate text for searching and for clicking.
This ensures we can still use Order#shipment although Spree deprecates
it, while fixing a bug at the same time. The problem that was making the
test fail was on `Order#shipment` that Spree defines.
If the shipments association changes, `#shipment` returns stale data.
That is because the order object we might be using is still alive, and
so its @shipment ivar still holds an old shipment object (it's not nil)
and thus `@shipment ||= shipments.last` doesn't evaluate the right-hand
side of the expression.
Note that we need to `prepend` the evaluation of the concern (which it's
been rename) for our methods to take precedence over Spree ones. With
`include`, Spree's `#shipment` would still be picked up making the test
fail.
This makes the default value of variant.on_demand false in all environments and in tests.
Additionally, adapt VariantStock.on_demand test and product factory to this change (setting on_hand value in product factory so it's not out of stock by default).
Unfortunately, the exact table row matcher doesn't wait correctly for
changes on the page. Waiting correctly would mean to assemble a very
complicated xpath similar to this gem:
https://github.com/jnicklas/capybara_table
Reverts dbf3a7aaaf9d458f99e14983ca9db2d4cbe4b564.
The reverted commit tried to avoid a 30 second delay by using
have_selector. While that was successful in reducing test time, it made
the matcher find rows that where not exactly the wanted row, but contained
text of the wanted row. This wasn't a problem until we experimented with
Chrome as test browser returns text on select boxes.
This commit makes the matcher precise again. We still have to deal with
the 30 second delay.
