[rspec-users] Assertions for asynchronous behaviour

Matt Wynne matt at mattwynne.net
Wed Sep 21 16:01:23 EDT 2011

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


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

More information about the rspec-users mailing list