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.
* Instead of decorating controller params, use our "Doublespeak"
mini-library to stub ActionController::Parameters. This prevents from
interfering with the params object if it is used in various ways, i.e.
if `params.fetch(...).permit(...)` is used instead of
`params.require(...).permit(...)`.
* Fix compat with Rails 4.1, where the verb for #update is PATCH not
PUT
* Track multiple calls to #permit within a given controller action
* Fix so that if the route for your action requires params (such as
:id) then you can specify those params
In Rails 4, the following construct:
has_many :children, conditions: { adopted: true }
changes to:
has_many :children, lambda { where(adopted: true) }
As a result, the way we check the conditions attached to a has_many
changes too: instead of accessing `reflection.options`, we have to use
`reflection.scope` -- this which refers to the lambda above, so we have
to evaluate it and then grab the `where` from the Relation that the
lambda returns.
The "flashes" instance variable that lives within FlashHash has changed
in Rails 4. I have added a shim to get the proper name.
Additionally, the set_the_flash matcher will dup the flash hash for the
controller on which it operates. As #dup does a shallow copy we need to
make sure to also copy the instance variables within the flash hash when
we do this. The Rails 4 version of FlashHash has an extra @discard
variable unlike the Rails 3 version so we make sure to copy that.
Rails 4 moved the layouts ivar from `@layouts` to `@_layouts`.
This change introduces what I have (for now) called the 'RailsShim'. The
idea is that this single class will house the rail version workarounds,
which can then be reused through the code. This paid off here because
both the spec and the implementation need access to the layouts ivar.