Delete test in rspec - change(Model, :count) failing - Why is reload needed?

Question

TLDR: App.count needs a reload to see a created record. Why?

I've found lots of references to testing a DELETE method that look like this:

expect { delete_request }.to change(App, :count).by(-1)

This makes sense, and works in some similar scenarios. However, I'm seeing an issue when testing for a delete that should NOT work, such as when no user is logged in.

Here is where I started, with two approaches to testing the same thing:

require 'rails_helper'

RSpec.describe V1::AppsController, type: :controller do
  let(:user) { create(:user) }
  let(:app) { create(:app, account: user.account) }

  describe 'DELETE destroy when you are not logged in' do
    let(:delete_request) { delete :destroy, id: app, format: :json }

    it 'does not delete the app (.count)' do
      expect { delete_request }.not_to change(App, :count)
    end

    it 'does not delete the app (.exists?)' do
      delete_request
      expect(App.exists?(app.id)).to eq(true)
    end
  end
end

This is what rspec said:

V1::AppsController
  DELETE destroy when you are not logged in
    does not delete the app (.count) (FAILED - 1)
    does not delete the app (.exists?)

Failures:

  1) V1::AppsController DELETE destroy when you are not logged in does not delete the app (.count)
     Failure/Error: expect { delete_request }.not_to change(App, :count)
       expected #count not to have changed, but did change from 0 to 1
     # ./spec/controllers/v1/delete_test_1.rb:11:in `block (3 levels) in <top (required)>'

2 examples, 1 failure

Note the most perplexing part: expected #count not to have changed, but did change from 0 to 1 . HUH? I attempt to make an illegal delete, and my record count grows by one? Also note that checking explicitly checking the subject record still exists works.

So I played around some more and found I could fix the problem with a reload prior to expect() :

it 'does not delete the app (.count)' do
  puts "App.count is #{App.count} (after create(:app))"
  app.reload
  puts "App.count is #{App.count} (after reload)"
  expect { delete_request }.not_to change(App, :count)
  puts "App.count is #{App.count} (after request)"
end

Now rspec is happy:

V1::AppsController
  DELETE destroy when you are not logged in
App.count is 0 (after create(:app))
App.count is 1 (after reload)
App.count is 1 (after request)
    does not delete the app (.count)
    does not delete the app (.exists?)

2 examples, 0 failures

From all this, I've decided to stick with the exists? approach. But another (possibly bigger) concern is that all the samples of tests I found on the interwebs to test for creating records like expect { create_request }.to change(App, :count).by(1) might be false positives, if they are seeing the same result as I am, and assuming the record was created when in fact it was a caching artifact?

So, any idea why App.count needs a reload to see the current value?

Answer 1

This happens because when ruby invokes the delete_request method, it invokes the app method, and it creates one App

To test this, create the app before calling the expect rspec method:

it 'does not delete the app (.count)' do
  app #creates the app
  expect { delete_request }.not_to change(App, :count)
end

Take a look at let's documentation:

Use let to define a memoized helper method. The value will be cached across multiple calls in the same example but not across examples.

Note that let is lazy-evaluated: it is not evaluated until the first time the method it defines is invoked. You can use let! to force the method's invocation before each example.

https://www.relishapp.com/rspec/rspec-core/v/2-11/docs/helper-methods/let-and-let