On 21 Sep 2011, at 17:46, Alex Chaffee wrote:
> There's a semantic issue in your eventually method that I'd like to
> discuss. My wait_for[1] and friends take a *predicate* (in the form of
> a block) and wait for it to return true(ish). Your eventually[2]
> ignores the return condition, and merely waits for it to not raise an
> error. I think using a predicate is more useful, and strictly no less
> powerful since the waiter code will *also* wait for it to not raise an
> error, so you could do *either* this
>
> eventually { rand(10) == 0 }
>
> or this
>
> eventually { rand(10).should == 0 }
>
> and if, after 2 sec or whatever, it keeps either being false or
> raising an ExpectationNotMetError, then the waiter will itself raise
> an ExpectationNotMetError.
>
> IOW, should the following pass or should it fail?
>
> eventually { false == true }
To be honest, I just ignored the true / false version in my implementation
because I want a helpful error message when the test fails, rather than a crude
TimeoutError or whatever.
I'm ambivalent about this: I would worry that allowing falsiness to cause an
assertion to be raised is not idiomatic RSpec, but perhaps it is idiomatic
Wrong, since you can do all that magic to infer an error message anyway, right?
I think as long as I can use my own assertions too I don't have any objections
to it doing both.
> P.S. (Lurkers please feel free to chime in too. :-)
>
> [1] https://github.com/pivotal/selenium/blob/master/lib/selenium/wait_for.rb
> [2] https://gist.github.com/1228927
cheers,
Matt
--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
