Caching issue - should it be cleared ?

[belgoros]

I'm using ActiveModel Serializers gem with Rails API and I tried to enable caching on `Address` following the docs of AMS as follows:

#serializers/address_serializer.rb


# frozen_string_literal: true


class AddressSerializer < ActiveModel::Serializer
  cache key: 'address', expires_in: 3.hours


  attributes :city,
             :id,
             :latitude,
             :longitude,
             :modified_by,
             :postal_code,
             :region,
             :street,
             :updated_at


  belongs_to :shop
end

But with this in place the previously passing request spec failed:

#spec/requests/address_spec.rb


require 'rails_helper'


RSpec.describe "Addresses", type: :request do
  let(:user)     { create(:user) }
  let!(:address) { create(:address, shop: user.shop)}
  let(:headers)  { valid_headers(user.username) }


describe 'PATCH /shops/:shop_identifer/address' do
    let(:valid_params) do
      ams_json(
        Address,
        city: address.city,
        postal_code: address.postal_code,
        street: 'new fancy street',
        modified_by: address.modified_by,
        shop: address.shop,
        id: address.id
      )
    end


    before { patch "/shops/#{address.shop.identifier}/address", params: valid_params, headers: headers }


    it 'returns status code 204' do
      expect(response).to have_http_status(204)
    end


    it 'updates the modified attributes' do
      updated = Address.find(address.id)
      expect(updated.street).to eq 'new fancy street'
    end
  end
end

with error:

1) Addresses PATCH /shops/:shop_identifer/address updates the modified attributes

 Failure/Error: expect(updated.street).to eq 'new fancy street'

 

 expected: "new fancy street"

 got: "7285 Dicki Circle"

 (compared using ==)

 # ./spec/requests/addresses_spec.rb:42:in `block (3 levels) in <top (required)>'

What am I missing? Thank you.

[Serguei Cambour]

Adding before(:example) hook to clear the cache seems to fix the problem. Is it the right way to go?

RSpec.describe "Addresses", type: :request do

  let(:user)     { create(:user) }

  let!(:address) { create(:address, shop: user.shop)}

  let(:headers)  { valid_headers(user.username) }

  

  before(:example) { Rails.cache.clear }

--
You received this message because you are subscribed to a topic in the Google Groups "rspec" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rspec/0m457NKBWFE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/90835c10-2133-4acb-9619-34fc01f368c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[belgoros]

On Tuesday, 23 April 2019 11:32:45 UTC+2, belgoros wrote:

Adding before(:example) hook to clear the cache seems to fix the problem. Is it the right way to go?

RSpec.describe "Addresses", type: :request do

  let(:user)     { create(:user) }

  let!(:address) { create(:address, shop: user.shop)}

  let(:headers)  { valid_headers(user.username) }

  

  before(:example) { Rails.cache.clear }

I found the solution proposed by Thoughtbot, - I added the following into my config/environments/test.rb:

config.cache_store = :null_store

and remove the line clearing Rails cache:

Rails.cache.clear

Now the failing example passes again:

it 'updates the modified attributes' do

  expect(address.reload.street).to eq 'new fancy street'
end

To unsubscribe from this group and all its topics, send an email to rspec+unsubscribe@googlegroups.com.

[Surya]

Although I'm not aware of your setup nor do I know what exactly you're trying to achieve.

However, the failing spec does state the fact that you're not updating it bursting your cache. What are the odds you not coming across this issue in production? As you wouldn't have a null store in prod, and if it continues to give you old address then I believe spec was broken for good reason.

Sent from phone, please ignore brevity.

To unsubscribe from this group and all its topics, send an email to rspec+un...@googlegroups.com.

To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/90835c10-2133-4acb-9619-34fc01f368c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.

To post to this group, send email to rs...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/ef16f471-582d-479f-88d0-28f58be65634%40googlegroups.com.

[Jon Rowe]

I was unaware serialisers cached attribute at the model level, how interesting.

Depending on what you want to test depends on how you should deal with it, if you don’t care about receiving fresh data either of your earlier solutions are fine. But you should consider if you want your update to “bust the cache” and return fresh data.

Cheers

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk

[Serguei Cambour]

Yeah, John, as I'm using active_model_serializers gem, it makes it possible to define caching in a serializer (model level).

What I was trying to achieve is to fix failing specs that passed before adding caching in serializers.

Thank you for your response.

--

You received this message because you are subscribed to a topic in the Google Groups "rspec" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rspec/0m457NKBWFE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/dejalu-217-6799f603-4dc3-400f-baf2-ab4fac66a9f2%40jonrowe.co.uk.

[Jon Rowe]

Hi Serghuei

What you mention is caching on the serialiser level unless I’m mistaken? I don’t see any reference to caching that would affect `find` however I could be wrong about your code!

My advice should still be relevant either way, you need to decide if your updates bust the cache, or wether you want to ignore the cache in tests only.

Happy testing!

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk