[rspec-users] Assertions for asynchronous behaviour

Matt Wynne
Wed, 21 Sep 2011 20:01:23 -0000

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