The `feature` and `scenario` names are aliases only available in feature
specs and not needed. It's confusing to have different names and we can
easily move feature specs to system specs when using standard names.
This spec file tried to access a class without loading the code. That
worked in usual spec runs when other specs were run first which
loaded the whole lib directory.
The OFN software was first written in Melbourne and a lot of spec code
relies on the state Victoria being in the database. When we imported
Spree code, it came with its default state Alabame in the USA. Having
two different defaults is confusing and caused specs to fail in rare
circumstances. Let's standardise it here which will also open the path
to removing the seeding of test data and the exclusion of states and
countries in the database cleaner.
Depending on the order of spec execution, it was possible that a factory
created the default state "Alabama" with the default country "USA"
instead of using the usual seed data of "Victoria" in "Australia". Some
specs rely on "Victoria" though and we now make sure that it's created
even if another spec created another country first.
The order_path route wasn't being inferred correctly from this Spree controller, causing errors to be thrown in the cart page if the number of editable orders was precisely one:
ActionView::Template::Error: undefined method `order_path'
Unfortunately, loading the migration code also reloads some Spree models
which causes errors later on. Another spec was failing with:
1) full-page cart viewing the cart when a product is soft-deleted shows the cart without errors
Failure/Error: variant.instance_variable_set :@hub, @hub
FrozenError:
can't modify frozen NilClass: nil
# ./lib/open_food_network/scope_variant_to_hub.rb:12:in `instance_variable_set'
The command to reproduce was:
rspec ./spec/features/consumer/shopping/cart_spec.rb[1:1:3:1]\
./spec/migrations/migrate_enterprise_fee_tax_amounts_spec.rb[1:1:1:1] --seed 0
I couldn't find a quick solution to make the migration not use app code.
Since the migration is a historical record now, it doesn't need repeated
testing.
