I stumbled across some spec code which was hiding an unexpected error. So I
fixed it properly. This code is to be replaced soon anyway and this is a tiny
step in that direction.
On `/admin/orders`, we now have a date range picker.
This spec seems to test only the behavior of flatpickr, which is an external dependencies ; we probably shouldn't test it since it's not our responsibilities. Leave the spec as it for now.
Previously, when changing the date range, we had several modals that opened.
Now, the `confirmRefresh()` method should be open only one time.
Update specs as well:
- use the method `accept_confirm`
- Removing pending and sleep as the spec is now green
We found that our database is quite busy querying the country all the
time. One source of these queries is the shop front which serializes
enterprises including their addresses. But addresses should be safe to
cache because:
- country records never change
- state records never change
- updating any other attribute changes the cache key
The caching was previously removed when the state_name attribute was
added. That is technically correct because it's possible to change a
state's name without updating the address. Then the cache would be out
of date. But we never update state names. And if we did, we would need
to invalidate the cache now.
With product validations being prioritized, custom and
insightful error messages were being overwriten by
general and ambiguous model validations, which
were confusing users
If a feature is activated or not depends on the database which is reset
after each test scenario. So enabling a feature doesn't leak into other
scenarios.
Just enabling the feature is less code and more realistic than mocking a
method call.
Routing specs and controller specs don't set warden on the request
environment. While we could try to re-implement Warden/Devise logic
here, it's much easier to not rely on the environment to be set.
While I'm usually opposed to changing production code to make testing
easier, it does avoid a lot of complication in this case. And maybe it
would be handy in other circumstances to have a more defensive approach
to checking the logged in user.
Check that businness address changes are ok
Test with another county since only one country and one state couldn't spot the fact that when changing country it needs to change also states selector
