* Fix the undefined method error for non rails project due to use of many? method
* Add tests for inclusion validation for non rails app.
* Remove unnecessary spaces.
* Rubocop offenses.
Co-authored-by: Nitin S <nitin.singh@edcast.com>
Co-authored-by: = <=>
When using a validation matcher in the negative, i.e.:
should_not validate_*(...)
as opposed to:
should validate_*(...)
...it's common to receive the following error:
undefined method `attribute_setter' for nil:NilClass
This happens particularly when using a matcher that makes use of
AllowValueMatcher or DisallowValueMatcher internally (which all of the
validation matchers do).
Whenever you make an assertion by using a matcher in the negative as
opposed to the positive, RSpec still calls the `matches?` method for
that matcher; however, the assertion will pass if that returns *false*
as opposed to true. In other words, it just inverts the result.
However, whenever we are using AllowValueMatcher or
DisallowValueMatcher, it doesn't really work to invert the result. like
this. This is because AllowValueMatcher and DisallowValueMatcher,
despite their name, aren't truly opposites of each other.
AllowValueMatcher performs these steps:
1. Set the attribute on the record to some value
2. Run validations on the record
3. Ask whether validations pass or fail
4. If validations fail, store the value that caused the failure along
with the validation errors and return false
5. Otherwise, return true
However, DisallowValueMatcher performs these steps:
1. Set the attribute on the record to some value
2. Run validations on the record
3. Ask whether validations pass or fail
4. If validations *pass*, store the value that caused the failure along
with some metadata and return false
5. Otherwise, return true
This difference in logic is achieved by having AllowValueMatcher
implement `does_not_match?` and then having DisallowValueMatcher use
this for its positive case and use `matches?` for its negative case.
It's easy to see because of this that `does_not_match?` is not the same
as `!matches?` and vice versa.
So a matcher that makes use of these submatchers internally needs to use
their opposite versions whenever that matcher is used in the negative
case. In other words, all of the matchers need a `does_not_match?` which
is like `matches?`, except that all of the logic is inverted, and in all
the cases in which AllowValueMatcher is used, DisallowValueMatcher needs
to be used.
Doing this ensures that when `failure_message` is called on
AllowValueMatcher or DisallowValueMatcher, step 4 in the list of steps
above stores a proper value that can then be referenced in the failure
message for the validation matcher itself.
The inclusion matcher, when qualified with `in_array`, was using
AllowValueMatcher to check that values outside the array were disallowed
by the model (and then inverting its result). However, it should have
been using DisallowValueMatcher all this time. This commit fixes that.
Without this fix, the following error is raised when using the inclusion
matcher against a model which does not have the proper inclusion
validation on it:
undefined method `attribute_setter' for nil:NilClass
This happens because the inclusion matcher is a complex matcher, i.e.,
it runs a series of submatchers internally and the result of those
submatchers contributes to whether or not the matcher matches. If one of
those submatchers fails, the inclusion matcher immediately fails and
spits out the failure message associated with that submatcher.
However, there is a fundamental difference between AllowValueMatcher and
DisallowValueMatcher as it relates to how they function:
* AllowValueMatcher sets an attribute to a value on a record and expects
the record not to fail validation.
* DisallowValueMatcher sets an attribute to a value on a record, but
expects the record *to* fail validation.
The issue in this case is that, because AllowValueMatcher was used
instead of DisallowValueMatcher, the inclusion matcher thought that the
AllowValueMatcher failed, when in fact it passed (this result was just
inverted). So it tried to generate a failure message for a matcher that
didn't fail in the first place. By using DisallowValueMatcher, we set
the proper expectations.
Instead of using
describe Foo do
# ...
end
use
RSpec.describe Foo, type: :model do
# ...
end
instead. This is not exactly official, as the former style still works,
but the latter style is highly suggested in RSpec documentation and the
like, so this is what people are used to.
[ci skip]
Since `ignoring_interference_by_writer` is on by default now, we don't
need to explicitly document it (unless someone wants to turn it off, but
that's unlikely).
[ci skip]
`allow_value` matcher is, of course, concerned with setting values on a
particular attribute on a particular record, and then checking that the
record is valid after doing so. That comes with a caveat: if the
attribute is overridden in such a way so that the same value going into
the attribute isn't the same value coming out of it, then `allow_value`
will balk -- it'll say, "I can't do that because that changes how I
work."
That's all well and good, but what the attribute intentionally changes
incoming values? ActiveRecord's typecasting behavior, for instance,
would trigger such an exception. What if the developer needs a way to
get around this? This is where `ignoring_interference_by_writer` comes
into play. You can tack it on to the end of the matcher, and you're free
to go on your way.
So, prior to this commit you could already apply it to `allow_value`,
but now in this commit it also works on any other matcher.
But, one little thing: sometimes using this qualifier isn't going to
work. Perhaps you or something else actually *is* overriding the
attribute to change incoming values in a specific way, and perhaps the
value that comes out makes the record fail validation, and there's
nothing you can do about it. So in this case, even if you're using
`ignoring_interference_by_writer`, we want to inform you about what the
attribute is doing -- what the input and output was. And so we do.
Modify descriptions and failure messages for all matchers by way of
allow_value and put small angle brackets around inspected values. This
is to visually distinguish an inspected value from the rest of the text,
and is especially noticeable for complex values such as an array that
contains an object, particularly if the inspected version of the value
wraps onto another line. It's a little easier to see:
When attempting to set :attr on Example to ‹[#<Child id:
nil>]›...
rather than:
When attempting to set :attr on Example to [#<Child id:
nil>]...
This is part of a collection of commits that aim to improve failure
messages across the board, in order to make matchers easier to debug
when something goes wrong.
* Make the description of the matcher more readable.
* Add boolean methods to check whether `allow_nil` or `allow_blank` have
been specified, to conform to the interface that ValidationMatcher
introduces.
* Fix or fill in tests involving failure messages and descriptions to
match these changes and recent changes to ValidationMatcher and
allow_value.
Why:
* The inclusion matcher (when used with the `in_array` qualifier) makes
the assertion that when the attribute is set to a value that is
outside the given array, the record in question is invalid. The issue
is that when used with a date or datetime attribute, the arbitrary
value the matcher chose was a string. This was getting typecast and so
the matcher was throwing a CouldNotSetAttributeError.
To satisfy the above:
* If the column is a date, use a Date for the arbitrary value
* If the column is a datetime, use a DateTime for the arbitrary value
* If the column is a time, use a Time for the arbitrary value
While we do advise against using the validates_inclusion_of or
validates_format_of validations with boolean columns, we won't judge
if you would like to do so.
Nitin Singh