mirror of
https://github.com/thoughtbot/shoulda-matchers.git
synced 2022-11-09 12:01:38 -05:00
c683aed2f0
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.
|
||
|---|---|---|
| .. | ||
| step_definitions | ||
| support | ||
| activemodel_integration.feature | ||
| independent_matchers.feature | ||
| rails_integration.feature | ||