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.
* Have the failure message describe more clearly what the `allow_value`
matcher was trying to do when it failed.
* Make the description of the matcher more readable.
* For each value that `allow_value` sets, use a different Validator
instance. The matcher still changes state as it runs, but a future
commit will refactor this further.
* Merge StrictValidator back into Validator, and remove it. The way that
StrictValidator worked (as a module that was mixed into an instance of
Validator at runtime) was confusing, and there's really no need to
split out the logic anymore.
* Fix or fill in tests involving failure messages and descriptions.
In Rails 4.2, ActiveRecord was changed such that if you attempt to set
an attribute to a value and that value is outside the range of the
column, then it will raise a RangeError. For instance, an integer column
with a limit of 2 (i.e. a smallint) only accepts values between -32768
and +32767.
This means that if you try to do any of these three things, a RangeError
could be raised:
* Use validate_numericality_of along with any of the comparison
submatchers and a value that sits on either side of the boundary.
* Use allow_value with a value that sits outside the range.
* Use validates_inclusion_of against an integer column. (Here we attempt
to set that column to a non-integer value to verify that the attribute
does not allow said value. That value is really a string version of a
large number, so if the column does not take large numbers then the
matcher could blow up.)
Ancillary changes in this commit:
* Remove ValidationMessageFinder and ExceptionMessageFinder in favor of
Validator, StrictValidator, and ValidatorWithCapturedRangeError.
* The allow_value matcher now uses an instance of Validator under the
hood. StrictValidator and/or ValidatorWithCapturedRangeError may be
mixed into the Validator object as needed.
This commit changes the failure message that `allow_value` generates so
that it reads a bit nicer.
When a call to #valid? resulted in validation messages, `allow_value`
formerly failed with this message:
Expected errors to include "the message" when attr is set to "some value", got errors: ["another message (attribute: \"attr\", value: \"some value\")", "some other message (attribute: \"attr2\", value: \"some other value\")"]
Now it fails with this message:
Expected errors to include "the message" when attr is set to "some value",
got errors:
* "another message" (attribute: attr, value: "some value")
* "some other message" (attribute: attr2, value: "some other value")
Similarly, when a call to #valid resulted in an exception, `allow_value`
formerly failed with this message:
Expected errors to include "the message" when attr is set to "some value", got: some message
Now it fails with this message:
Expected errors to include "the message" when attr is set to "some value",
got: "some message"
allow_value currently gives an error message that looks like this:
Expected errors to include "must be greater than 0" when amount is set to 0, got errors: ["amount must be greater than 0.0 (0)"]
This is confusing because the error message here is "must be greater than 0.0",
not "amount must be greater than 0.0".
With this commit the message changes to:
Expected errors to include "must be greater than 0" when amount is set to 0, got errors: ["must be greater than 0.0 (attribute: "amount", value: 0)"]
Elliot Winkler