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.
If a subtest fails, explain why. We're going to be adding another
subtest later, and so without this extra information, users will most
definitely be confused.
Also add a helper method, `build_scenario_for_validation_matcher`, to
all unit tests.
Our plan is to slowly transition all of the tests to use this helper
method, and that we we can get rid of the umpteen different ways we are
building records across all of the tests.
Oftentimes our shared example groups represent tests for qualifiers.
It's more natural to say "it supports ignoring_interference_by_writer"
instead of "it behaves like it supports
ignoring_interference_by_writer".
v3.3 introduced a new feature: the ability to re-run failed specs. v3.4
contains some other nifty features, such as code highlighting and
compound failure messages.
This is an effort to vastly decrease the time it takes to run a single
unit test file and therefore increase productivity and happiness for
people working on this project.
If you want to run a unit test file, now you can use `zeus rspec`
instead of `rspec` -- assuming you run `zeus start` first -- and it will
run a LOT faster.
Because test files tend to have long file paths, you can even use a
shorter version of those paths. So instead of saying:
zeus rspec spec/unit/shoulda/matchers/active_record/validate_uniqueness_of_matcher_spec.rb
you can say:
zeus rspec active_record/validate_uniqueness_of_matcher_spec.rb
* For some reason, ActiveRecord was printing a warning saying that
"active_record/base" was already being loaded and there was a possible
circular dependency. We fix this by explicitly requiring
"active_record/base" before `$VERBOSE` is set to true.
* We were getting warnings when re-defining Kernel.capture,
Kernel.silence_stream and Kernel.silence_stderr, so undefine them
first.
In order to write tests for the `word_wrap` method we have, we need a
spec helper that we can require. We don't need anything fancy. The
doublespeak_spec_helper is doing most of what we want except for the
Doublespeak require.
Today if we run a single file or spec like `callback_matcher_spec.rb` or
`callback_matcher_spec.rb:12` the formatter is the default dot.
With this config when we run a single file or spec the formatter is the
documentation and when we run the suite the formatter is the default dot.
When running tests, you can now switch between running them against a
SQLite or PostgreSQL database. This is accomplished by modifying the
unit and acceptance tests so that when they generate and load the test
Rails application, database.yml is replaced with content that will
configure the database appropriately.
If you attempt to run tests without specifying an Appraisal, then you
will be going off of the main Gemfile. The Gemfile is not guaranteed to
contain all of the dependencies necessary to run tests, so it is very
likely that you'll get an obscure error somewhere. Instead of letting
this happen, raise a specific error.
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.
Modify helper methods provided by ControllerBuilder so that we use as
much of rspec-rails's controller example group capabilities as possible.
All of this can still be improved but this is a good start for now.
Currently before running unit tests we are getting auto-required before
rspec-rails is getting required. This is bad because we need to wait
until rspec-rails is loaded before injecting Shoulda::Matchers::* into
the current RSpec context, otherwise matchers that clash with
rspec-rails (such as `render_template` will get overridden).
This is happening when creating and booting the Rails application.
Bundler will auto-require any gems in the Gemfile. One of these gems is
ourselves (via the `gemspec` line). Since there aren't any dependencies
in the gemspec, there's no need for us to be in the Gemfile.
This means that we no longer have to explicit `include` Rails
ActionController template assertions in the tests for `render_template`
as they should get included automatically for us.
When running unit tests we need to ensure that we are simulating how
other people will use the matchers as best we can. This means, for
instance, tagging any example groups that test controller matchers as
controller example groups.
* Change 'spec' Rake task to 'spec:unit'
* Require unit_spec_helper.rb in unit tests, not spec_helper.rb
* Re-namespace files in spec/support/unit under UnitTests
* Files in spec/support/unit/helpers no longer automatically add
themselves to RSpec - this happens in unit_spec_helper.rb
* Extract RecordWithDifferentErrorAttributeBuilder and
RecordValidatingConfirmationBuilder to separate files
* Move spec/shoulda to spec/unit_tests/shoulda
* Move spec/support/*.rb to spec/support/unit_tests/{helpers,matchers}
* Move spec_helper.rb to unit_spec_helper.rb
Kapil Sachdev