2014-10-22 20:54:36 -04:00
|
|
|
require 'shoulda/matchers/configuration'
|
2020-08-26 12:24:28 -04:00
|
|
|
require 'shoulda/matchers/doublespeak'
|
|
|
|
|
require 'shoulda/matchers/error'
|
|
|
|
|
require 'shoulda/matchers/independent'
|
|
|
|
|
require 'shoulda/matchers/integrations'
|
|
|
|
|
require 'shoulda/matchers/matcher_context'
|
|
|
|
|
require 'shoulda/matchers/rails_shim'
|
|
|
|
|
require 'shoulda/matchers/util'
|
Handle ensure_inclusion_of for boolean columns
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.
2014-01-21 18:46:23 -05:00
|
|
|
require 'shoulda/matchers/version'
|
Fix delegate_method when used with shoulda-context
When specifying a custom subject, a straightforward usage of
`delegate_method`, such as the following
class UserPresenter
delegate :id, to: :user
attr_reader :user
def initialize(user)
@user = user
end
end
class UserPresenterTest < ActiveSupport::TestCase
subject { UserPresenter.new(User.new) }
should delegate_method(:id).to(:user)
end
would error with something like:
ArgumentError: wrong number of arguments (0 for 1)
This happens because the `should` method in shoulda-context asks the
DelegateMethodMatcher object for its description so that it can use it
to give the test a name and create a method that Test::Unit can run.
Now, the matcher's description needs a subject in order to determine
whether a class or an instance is being tested here -- if a class is
being tested the description will be "should delegate #id to \#user
object", if a class then "should delegate .id to .user object".
Unfortunately the matcher doesn't know what the subject is before
its #description method is called -- it only knows about this when it
gets evaluated.
Within the matcher we do have access to the current context class, so we
could read the subject block off of it and evaluate it. However, in
order to properly do this we also need access to the instance of the
test itself, which we do not have until the matcher is evaluated (by
which point it's too late).
Since there's really no way to solve this problem apart from rewriting a
lot of shoulda-context, and since often times your subject is an
instance and not a class, just assume it's an instance in this case.
2014-09-12 18:39:48 -04:00
|
|
|
require 'shoulda/matchers/warn'
|
2011-01-31 16:30:31 -05:00
|
|
|
|
2020-08-26 12:24:28 -04:00
|
|
|
require 'shoulda/matchers/action_controller'
|
|
|
|
|
require 'shoulda/matchers/active_model'
|
|
|
|
|
require 'shoulda/matchers/active_record'
|
|
|
|
|
require 'shoulda/matchers/routing'
|
|
|
|
|
|
2014-10-22 20:54:36 -04:00
|
|
|
module Shoulda
|
|
|
|
|
module Matchers
|
|
|
|
|
class << self
|
2015-03-01 03:20:41 -05:00
|
|
|
# @private
|
2014-10-22 20:54:36 -04:00
|
|
|
attr_accessor :assertion_exception_class
|
|
|
|
|
end
|
|
|
|
|
end
|
2014-04-04 17:02:18 -04:00
|
|
|
end
|