[rspec-users] [RSpec] implicit receiver for should problem when helper predicate methods are in use
dchelimsky at gmail.com
Fri May 8 03:50:49 EDT 2009
On Thu, May 7, 2009 at 11:06 PM, Jarmo Pertman <Jarmo.P at gmail.com> wrote:
> 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.
You're correct. I misunderstood.
> 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.
This is pretty helpful, thanks for a more thorough explanation. I did
add your patch locally, however, and it doesn't seem to solve the
problem (I still get undefined method `ok?' when I run the example in
your 2nd post).
I need to think about this some more before I agree to go in this
direction, as I want to make sure there are no negative impacts that
I'm not thinking of right now. That said, I'd need a patch w/ specs
that fail without this change and pass with this change. Please file a
ticket at http://rspec.lighthouseapp.com w/ a patch.
> 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?
Good point - thanks! :
>> 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.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users