On Thu, May 7, 2009 at 11:06 PM, Jarmo Pertman <jarm...@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 : > $browser.text.include?(text) > end > > def login user_id > # do something so user would be logged in > end > > def logged_in? user_id > # return true if user is logged in > end > > def start_browser_on_url url > $browser = Browser.new > $browser.goto url > end > end > > describe "my test" do > include WatirHelperMethods > > before :all do > start_browser_on_url "http://url"; > end > > it "should log user into application" do > login "testuser" > should be_logged_in > should have_text("Welcome testuser") > end > > after :all do > $browser.close > end > end > > 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. Cheers, David > 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! : http://github.com/dchelimsky/rspec/commit/b061f9f40dc8a29d34ddb3e74427b244bbcf0aa8 > > Jarmo > >> >> 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
