Rails 4 does not recognise requests to destroy routes without ids as valid routes.
Fixes:
14) LineItemsController destroying a line item on a completed order without a line item id fails and raises an error
Failure/Error: delete :destroy
ActionController::UrlGenerationError:
No route matches {:action=>"destroy", :controller=>"line_items"}
# ./spec/controllers/line_items_controller_spec.rb:46:in `block (5 levels) in <top (required)>'
ActionController doesn't accept nil values for :id as a valid route request in Rails 4.
Fixes:
2) Api::OrdersController#show Resource not found when no order number is given
Failure/Error: get :show, id: nil
ActionController::UrlGenerationError:
No route matches {:action=>"show", :controller=>"api/orders", :id=>nil}
# ./spec/controllers/api/orders_controller_spec.rb:168:in `block (4 levels) in <module:Api>'
The headers in the request were not being populated correctly in the test, so the #api_key method was not functioning as intended.
Fixes:
48) Api::BaseController cannot make a request to the API with an invalid API key
Failure/Error: expect(json_response).to eq( "error" => "Invalid API key (fake_key) specified." )
expected: {"error"=>"Invalid API key (fake_key) specified."}
got: {"products"=>[]}
(compared using ==)
Diff:
@@ -1,2 +1,2 @@
-"error" => "Invalid API key (fake_key) specified.",
+"products" => [],
# ./spec/controllers/api/base_controller_spec.rb:40:in `block (3 levels) in <top (required)>'
In order to make the spec fail if the controller was not thread safe, it
uses breakpoints. One of those breakpoints was set for a method that has
now been removed.
I changed the method that is used for the breakpoint and changed `allow`
to `expect` so that this spec will fail if we remove that method as
well. Future version of Rspec will check if a mocked method actually
exists but our version just mocks it anyway. This is one way how specs
can become invalid after refactoring.
The spec was setting the order's state to "complete" but didn't save
that state to the database. The new locking mechanism is was reloading
the order which loaded the cart state again. And since the order.next
method was mocked to just return true, the controller was trying to do
that in an infinite loop.
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.
