shoulda matchers do not play nicely with normalized values / setters

[mareczek]

Model:

class Event < ActiveRecord::Base
  validates :name,
    presence: true,
    uniqueness: { scope: [:deleted_at], case_sensitive: false },
    length: { minimum: 3, maximum: 12 }

  normalize :name, with: [:upcase, :strip, :squish, :blank]
end

RSpec:

describe Event do
  describe "validations" do
    it { expect(event).to validate_presence_of(:name) }
    it { expect(event).to validate_length_of(:name).is_at_least(3).is_at_most(12) }
    it { expect(event).to validate_uniqueness_of(:name).scoped_to(:deleted_at).case_insensitive }
  end
end

RSpec output:

Failures:

  1) Event validations should ensure name has a length between 3 and 12
     Failure/Error: it { expect(event).to validate_length_of(:name).is_at_least(3).is_at_most(12) }

     Shoulda::Matchers::ActiveModel::AllowValueMatcher::CouldNotSetAttributeError:
       The allow_value matcher attempted to set :name on Event to "xx", but
       when the attribute was read back, it had stored "XX" instead.

       This creates a problem because it means that the model is behaving in a
       way that is interfering with the test -- there's a mismatch between the
       test that was written and test that was actually run.

       There are a couple of reasons why this could be happening:

       * The writer method for :name has been overridden and contains custom
         logic to prevent certain values from being set or change which values
         are stored.
       * ActiveRecord is typecasting the incoming value.

       Regardless, the fact you're seeing this message usually indicates a
       larger problem. Please file an issue on the GitHub repo for
       shoulda-matchers, including details about your model and the test
       you've written, and we can point you in the right direction:

       https://github.com/thoughtbot/shoulda-matchers/issues
     # ./spec/models/event_spec.rb:26:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:33:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:32:in `block (2 levels) in <top (required)>'
     # -e:1:in `<main>'

  2) Event validations should require unique value for name scoped to deleted_at
     Failure/Error: it { expect(event).to validate_uniqueness_of(:name).scoped_to(:deleted_at).case_insensitive }

     Shoulda::Matchers::ActiveModel::AllowValueMatcher::CouldNotSetAttributeError:
       The allow_value matcher attempted to set :name on Event to "a", but
       when the attribute was read back, it had stored "A" instead.

       This creates a problem because it means that the model is behaving in a
       way that is interfering with the test -- there's a mismatch between the
       test that was written and test that was actually run.

       There are a couple of reasons why this could be happening:

       * The writer method for :name has been overridden and contains custom
         logic to prevent certain values from being set or change which values
         are stored.
       * ActiveRecord is typecasting the incoming value.

       Regardless, the fact you're seeing this message usually indicates a
       larger problem. Please file an issue on the GitHub repo for
       shoulda-matchers, including details about your model and the test
       you've written, and we can point you in the right direction:

       https://github.com/thoughtbot/shoulda-matchers/issues
     # ./spec/models/event_spec.rb:27:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:33:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:32:in `block (2 levels) in <top (required)>'
     # -e:1:in `<main>'

Is there a way to tell a shoulda_matchers that the attribute is in some way normalized so it doesn't raise these notifications?

[mcmire]

Yes, there will be a way to get around this in the next immediate release by using an additional qualifier, so you'll be able to say:

it do
  expect(event).
    to validate_length_of(:name).
    is_at_least(3).
    is_at_most(12).
    ignoring_interference_by_writer
end

(refs #866)

[mareczek]

Very cool! Thanks!!!

[mcmire]

@mareczek This should now be fixed. Would you be willing to point to master in your app's Gemfile and see if that fixes the tests that were failing?

[mareczek]

Of course! Will let you know in a sec

[mareczek]

MY BAD! Works great, I did not specify the travel_duration to be only integer.

disregard post below

The cases that I showed in the issue work but a different case remains broken:
Model:

class DurationRule < ActiveRecord::Base
  validates :travel_duration, presence: true, numericality: { greater_than: 0 }
end

RSpec

    it do
      should validate_numericality_of(:travel_duration).is_greater_than(0).only_integer
    end

RSpec output:

Failures:

  1) DurationRule validations d
     Failure/Error: should validate_numericality_of(:travel_duration).is_greater_than(0).only_integer

       DurationRule did not properly validate that :travel_duration looks like
       an integer greater than 0.
         In checking that DurationRule disallows :travel_duration from being a
         decimal number, after setting :travel_duration to ‹0.1› -- which was
         read back as ‹0› -- the matcher expected the DurationRule to be
         invalid, but it was valid instead.

         As indicated in the message above, :travel_duration seems to be
         changing certain values as they are set, and this could have something
         to do with why this test is failing. If you've overridden the writer
         method for this attribute, then you may need to change it to make this
         test pass, or do something else entirely.
     # ./spec/models/duration_rule_spec.rb:68:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:33:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:32:in `block (2 levels) in <top (required)>'
     # -e:1:in `<main>'

Finished in 1.23 seconds (files took 0.51902 seconds to load)
1 example, 1 failure

[mareczek]

Will this be release to a specific version any time soon?

[mcmire]

Yeah, I still need to finish #841 and #864, but those should be simple, and then I'll release 3.0.2.