Why:
* Previously, `allow_value` would raise a CouldNotSetAttributeError
if the value being set didn't match the value the attribute had after
being set, but only if the attribute was being changed from nil to
non-nil or non-nil to nil.
* It turns out it doesn't matter which value you're trying to set the
attribute to -- if the attribute rejects that change it's confusing
either way. (In fact, I was recently bit by a case in which I was
trying to validate numericality of an attribute, where the writer
method for that attribute was overridden to ensure that the attribute
always stored a number and never contained non-number characters.
This ended up making the numericality validation useless, of
course -- but it caused confusion because the test acted in a way
I didn't expect.)
To satisfy the above:
* `allow_value` now raises a CouldNotSetAttributeError if the attribute
rejects the value being set in *any* way.
* However, add a `ignoring_interference_by_writer` qualifier so that
it is possible to manually override this behavior.
* Fix tests that are failing now because of this new change:
* Fix tests for allow_value matcher
* Fix tests for numericality matcher
* Remove tests for numericality matcher + integer column
* An integer column will typecast any non-integer value to an
integer.
* Because of the typecasting, our tests for the numericality matcher
against an integer column don't quite work, because we can't
really test what happens when the attribute is set to a
non-integer value. Now that `allow_value` is more strict, we're
getting a CouldNotSetAttributeError when attempting to do so.
* The tests mentioned were originally added to ensure that we are
handling RangeErrors that ActiveRecord used to emit. This doesn't
happen anymore, so the tests aren't necessary anymore either.
* Fix tests for acceptance matcher
* Fix tests for absence matcher
If you have a model that declares `has_secure_password` and you also
have a presence validation on the password, and you write a test against
this validation using an instance of your model where the password is
already set, then your test will fail. This is because
has_secure_password (at least on Rails 4) defines #password= such that
if it is given nil, then the password will not be overwritten with nil.
This interferes with how our validate_presence_of matcher works.
Unfortunately there is not a great way to get around this (using
\#write_attribute won't work, either). So in this case we raise a
helpful error message that instructs the user to use an empty record
against `validates_presence_of`.
Currently, using `ensure_inclusion_of` against a boolean column doesn't
work. We can assert that the column allows boolean values, but what
about values that should be rejected? Well, it depends on what you give
to `ensure_inclusion_of`. Here's how it works now:
* `ensure_inclusion_of(:attr).in_array([true])` asserts that false is
rejected
* `ensure_inclusion_of(:attr).in_array([false])` asserts that true is
rejected
* `ensure_inclusion_of(:attr).in_array([true, false])` does not assert
that anything is rejected, instead informing the developer how
this sort of expectation is not fully testable (anything other than
true, false, or nil will be converted to false).
* `ensure_inclusion_of(:attr).in_array([nil])`, when the column is
nullable, does not assert that anything is rejected, either, also
printing a warning
* `ensure_inclusion_of(:attr).in_array([nil])`, when the column is
non-nullable, raises an error because this expectation is not testable
in any way, as setting a boolean column to nil this way will get
converted to false.
Elliot Winkler