1
0
Fork 0
mirror of https://github.com/thoughtbot/shoulda-matchers.git synced 2022-11-09 12:01:38 -05:00
thoughtbot--shoulda-matchers/lib/shoulda/matchers/matcher_context.rb

37 lines
674 B
Ruby
Raw Normal View History

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
module Shoulda
module Matchers
2014-12-25 01:13:30 -05:00
# @private
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
class MatcherContext
def initialize(context)
@context = context
end
def subject_is_a_class?
if inside_a_shoulda_context_project? && outside_a_should_block?
assume_that_subject_is_not_a_class
else
context.subject.is_a?(Class)
end
end
protected
attr_reader :context
private
def inside_a_shoulda_context_project?
defined?(Shoulda::Context)
end
def outside_a_should_block?
context.is_a?(Class)
end
def assume_that_subject_is_not_a_class
false
end
end
end
end