The `Spree::Admin::OrdersController`'s test file quite long (as well as
the controller itself) but it'll grow more in the upcoming commits.
That's just a symptom of that controller having too many
responsibilities. It does much more than CRUD on `Spree::Order` (the
Rails convention).
Things like invoices are an entity on their own and would better fit
into a `InvoicesController`. Hopefully, splitting up the tests is hint
for the next dev to do that.
Setting a tax rate to included fails a validation if a default zone doesn't exist, so that's added. Also improved the tested scenarios and some of the details checked on the updated objects.
BigDecimal was throwing an error here (in Rails 5) unless it received a string, but I think this is actually an issue with the way params were being passed in the relevant spec, as opposed to the controller itself.
This method is named "update distribution charge". What this method actually does is delete all of the fee adjustments on an order and all it's line items, then recreate them all from scratch. We call this from lots of different places all the time, and it's incredibly expensive. It even gets called from inside of transactions being run inside callbacks. Renaming it hopefully will add a bit of clarity.
This needs to be a lot more granular!
This removes the following two deprecation warnings that we are getting
by millions (the two for each controller action test):
```
DEPRECATION WARNING: You are trying to generate the URL for a named route called "main_app" but no such route was found. In the future, this will result in an `ActionController::UrlGenerationError` exception. (called from process_action_with_route at /usr/
src/app/spec/support/controller_requests_helper.rb:49)
DEPRECATION WARNING: Passing the `use_route` option in functional tests are deprecated. Support for this option in the `process` method (and the related `get`, `head`, `post`, `patch`, `put` and `delete` helpers) will be removed in the next version without
replacement. Functional tests are essentially unit tests for controllers and they should not require knowledge to how the application's routes are configured. Instead, you should explicitly pass the appropiate params to the `process` method. Previously th
e engines guide also contained an incorrect example that recommended using this option to test an engine's controllers within the dummy application. That recommendation was incorrect and has since been corrected. Instead, you should override the `@routes`
variable in the test case with `Foo::Engine.routes`. See the updated engines guide for details. (called from process_action_with_route at /usr/src/app/spec/support/controller_requests_helper.rb:49)
```
It slows down our test suite and clutters the output a lot. As per my
investigation, this is something that arose in
https://github.com/rails/rails/pull/17453 and addressed in
https://github.com/rails/rails/pull/17725. TL;DR: Engines need to define
their routes in controller tests as shown in
https://github.com/discourse/discourse/pull/3011.
This, however, revealed a much complex reality in our case. We're still
using a `Spree::Core::Engine` with its own routes at
`Spree::Core::Engine.routes`. So we can't skip defining `routes { }` for
each of its controllers unless we merge this engine into our app, but
that's going to require more effort. What could that entail in
https://github.com/openfoodfoundation/openfoodnetwork/compare/master...coopdevs:move-users-to-app-routes.
To make it even worse, note that we override spree's core routes from
our own, resulting in a controller whose actions are being served from
routes defined in either `config/routes.rb` or `config/spree/routes.rb`
🙈.
