WIP: Add converting_values to validation matchers

[mcmire]

This is WIP as I add tests for every matcher to which this applies.

I don't like the idea of blindly ignoring any CouldNotSetAttributeError that may arise from using a particular matcher. It may very well be that the exception could be raised for a good reason. So instead of doing this, I'm proposing a new matcher: converting_values (or its companion, converting_value_to, for allow_value). The idea here is that you give the matcher a whitelist of acceptable values and their converted forms. So if the matcher detects a CouldNotSetAttributeError, but the value it sent to the attribute and the value it got out are both in this whitelist, then it'll ignore the exception and move on.

I think this is preferable over supplying some kind of lambda (which I proposed in #799) because at that point you'd probably be copying or recreating the same logic you have in the model. I think that by explicitly listing the acceptable values it's far easier to control and it's more clear to someone reading the test what's going on.

• numericality
• absence
• acceptance
• confirmation
• exclusion (producing a test case here is difficult)
• inclusion (producing a test case here is difficult)
• length
• presence (the only thing that's set on the record is nil, and we are handling value conversions here so as long as the final value is blank)
• uniqueness (this actually creates a lot of problems so we should probably raise a specific error?)

[houndci-bot]

Put a comma after the last parameter of a multiline method call.

[houndci-bot]

Put a comma after the last parameter of a multiline method call.

[houndci-bot]

Prefer single-quoted strings when you don't need string interpolation or special symbols.

[mcmire]

After thinking about it, I'm not sure I like this approach -- if you have a test that uses a factory to build a record, and a value for the attribute being tested is provided within the factory itself, and the matcher fails because that value is getting changed somehow, it doesn't really make sense to use converting_values to fix that issue, because you'll have this value that's referred to in the test out of context.

In other words, if you have this factory:

factory :user do
  username "some_username"
end

and this model:

class User < ActiveRecord::Base
  def username=(username)
    super(username.downcase)
  end
end

and you have this test:

describe User do
  context "validations" do
    it do
      create(:user)
      should validate_uniqueness_of(:username)
    end
  end
end

it wouldn't make sense to say:

describe User do
  it do
    should validate_uniqueness_of(:username).
      converting_values("SOME_USERNAME" => "some_username")
  end
end

because a reader of this test wouldn't even know where this comes from.

In fact, if you saw:

describe User do
  it do
    should validate_uniqueness_of(:username).
      converting_values("A" => "a")
  end
end

would you be confused where "A" is coming from? I might.

So, perhaps we do this instead:

• Add ignoring_interference_by_writer to every matcher as in Added support for ignoring_interference_by_writer to validate_uniqueness_of #800.
• Still keep track of changes to values, but don't worry about them, unless the matcher fails -- at that point, print out any value changes, in case this has something to do with the failure (at least it'll give me a way to see what's going on).

[mcmire]

Closing this in favor of #866.