base_spec_helper now defines configs that are universal, whereas spec_helper is for configs that are using DatabaseCleaner and Selenium. This means we can include the base_spec_helper in both the system test setup and the regular setup but separate the other configurations for each type.
This is a slippery slope and there's perfectly reasonable arguments against doing this, but on a practical level I think retrying the occasional flaky spec (and adding an extra 10 seconds or so on to the build time) is categorically better than failing the build and having to restart the whole thing (potentially multiple times).
The configuration can go into the central .simplecov file and then we
just need to `require` simplecov to start the coverage process. This
also avoids duplicating the config if we want to start simplecov from
the rails server to cover the lines used in by the server in feature
specs.
https://github.com/simplecov-ruby/simplecov#using-simplecov-for-centralized-config
The CI build can't find the downloaded file and fails like:
```
2) enterprise fee summaries csv downloads smoke test for generation of report based on permissions when logged in as enterprise user generates file with data for the enterprise
Failure/Error: sleep 0.1 until downloaded?
Timeout::Error:
execution expired
# ./spec/support/downloads_helper.rb:34:in `sleep'
# ./spec/support/downloads_helper.rb:34:in `block in wait_for_download'
# ./spec/support/downloads_helper.rb:33:in `wait_for_download'
# ./spec/support/downloads_helper.rb:11:in `downloaded_filename'
# ./engines/order_management/spec/features/order_management/reports/enterprise_fee_summaries_spec.rb:119:in `block (5 levels) in <top (required)>'
# ./engines/order_management/spec/features/order_management/reports/enterprise_fee_summaries_spec.rb:80:in `block (4 levels) in <top (required)>'
# ./spec/support/downloads_helper.rb:22:in `with_empty_downloads_folder'
# ./engines/order_management/spec/features/order_management/reports/enterprise_fee_summaries_spec.rb:80:in `block (3 levels) in <top (required)>'
```
No need to slow down the build with partial coverage analysis that won't
be merged in a single report for the whole build.
Also, this makes builds fail because we are not running the whole suite.
We set this value to `true` unconditionally in an initializer, and then check the value in various places via Spree::Config. It's never false, and it's not configurable, so we can just drop it and remove the related conditionals. 🔥
We're in Rails 4.2 so we can remove it. This gets rid of the following
message when running tests:
```
DEPRECATION WARNING: Suppressing Selenium deprecation warnings is not needed any more. (called from block in <top (required)> at /usr/src/app/spec/spec_helper.rb:214)
```
Devise has been complaining about this for a while in the test suite:
```
[Devise] including `Devise::TestHelpers` is deprecated and will be removed from Devise.
For controller tests, please include `Devise::Test::ControllerHelpers` instead.
```
In v5 the default value is true, that means that all parent objects (for example the order od a line item) will be built using the same strategy as the object (build or create), in v4 and now with this config, the parent is always created
We can revert this and use the default value but that will require some adaptions, quite a lot of specs are broken with that behaviour activated
Apparently, although we tend to add the type of spec file some RSpec
methods are not working without it. We're getting:
```
NoMethodError:
undefined method `helper' for RSpec::ExampleGroups::SpreeSharedOrderDetailsHtmlHaml:Class
```
```
NameError:
undefined local variable or method `controller' for #<RSpec::ExampleGroups::SpreeAdminUsersController::AuthorizeAdmin:0x00007fa8b32addf8>
# ./spec/controllers/spree/admin/users_controller_spec.rb:10:in `block (3 levels) in <top (required)>'
```
It needs more investigation but another day.
When two people tried to buy the same item at the same time, it was
possible to oversell the item and end up with negative stock.
Parallel checkouts could also lead to other random failures. This spec
is testing that scenario by starting two threads which would run into a
race condition unless they use effective synchronisation. The added spec
fails if the synchronisation is removed from the CheckoutController.
