[rspec-users] [RSpec] implicit receiver for should problem when helper predicate methods are in use

Jarmo Pertman Jarmo.P at gmail.com
Mon May 11 17:30:58 EDT 2009

Thanks for adding this change into repo!
I'm quite surprised that anyone else haven't stumbled upon this
problem yet. I guess it's because most of spec'ing is done for Ruby
projects, so this functionality is not needed.

I have been thinking a little more about this topic and asked myself:
why not make it backwards compatible without explicitly stating
subject as 'self'? If not making it backwards compatible then all my
current specs which use Watir would have to be changed by adding
"subject {self}" to them.

Why just not use ExampleGroup as a receiver for #should when string is
used in ExampleGroup description? I cannot see any negative impacts on
that change and rake specs are also passing. Any ideas where this
might fail? There probably aren't any specs where description is
written as a string and then you want to invoke matchers against that
string... Doesn't seem logical to me.

So, I've changed locally should method in
Spec::Example::Subject::ExampleMethods from:

        def should(matcher=nil)
          self == subject ? self.__should_for_example_group__
(matcher) : subject.should(matcher)

        def should(matcher=nil)
          if self == subject || (subject.is_a?(String) && subject ==

I've added that "&& subject == instance_eval(&self.class.subject)"
part as an extra precaution, but i don't have any ideas, why it's
needed anyway, because I cannot think of any cases where string is
used as a subject... or maybe there are some libraries, which monkey-
patch String and want to call #should implicitly?! :)

in short, at the moment this seems to work also (rake specs are
passing again):
        def should(matcher=nil)
          if self == subject || subject.is_a?(String)

If you think that this functionality might be reasonable for wider use
(some other Watir or similar library users for example), then I can
provide a patch with specs.


More information about the rspec-users mailing list