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

Jarmo Pertman Jarmo.P at gmail.com
Fri May 8 02:06:10 EDT 2009

I think that I don't understand what you mean by that exactly. I mean,
I patched the should and should_not methods in moule
Subject::ExampleMethods themselves, which means that this changes only
behaviour of subject itself e.g. it is already part of RSpec and don't
see how it would break matchers outside of RSpec. Please correct me if
i'm wrong.

Anyway, wasn't that Watir example good enough? I think that You're
right when You think that this thing should not be needed when testing
Ruby code with RSpec, but as soon as I start using Watir or some
similar tool, then I need to write bunch of helper methods to make my
specs less verbose. Let me try to make it more clear.

module WatirHelperMethods
    def has_text? text
      text.is_a?(Regexp) ? $browser.text =~ text :

    def login user_id
      # do something so user would be logged in

    def logged_in? user_id
      # return true if user is logged in

    def start_browser_on_url url
      $browser = Browser.new
      $browser.goto url

describe "my test" do
    include WatirHelperMethods

    before :all do
      start_browser_on_url "http://url"

    it "should log user into application" do
      login "testuser"
      should be_logged_in
      should have_text("Welcome testuser")

   after :all do

Something like this. Do You see where I'm going? Or am I doing
something what I ain't suppose to do ever? Should I just make
WatirHelperMethods as a class instead of module so it would work like
this: helper = HelperClass.new($browser); helper.login "testuser"...?
Doesn't remove much of a verboseness also.

I have also another question: why the should and should_not methods in
Spec::Example::Subject::ExampleMethods have this if statement anyway?
I mean, the matcher argument has it's default value as nil and it is
also as nil on Kernel#should(_not) method so this if doesn't make
sense to me. Can't it just be written as subject.should(matcher)? Or
is it just some code block which is written like that because of some
3rd party tools?


> The first problem is the dependency on subject, which is a construct
> from rspec's example groups. This would make rspec's matchers unusable
> outside rspec.
> I'm also not clear on what your goal is, per my earlier response.
> Please help me understand.

More information about the rspec-users mailing list