On Apr 19, 4:08 pm, David Chelimsky <[email protected]> wrote:
> OK - I think I understand this better from this example. The idea here is
> that the matcher should keep asking if div.text == "after" until it returns
> true or 2 seconds have passed, whichever comes first, after which it fails.
> Correct? If so, then this is different from what I was envisioning with
> "within(2).seconds { ... }"
When div.text == "after" before timeout of 2 seconds, then it passes
of course, but i guess you just typed it wrong here. What did you
envision then, could you explain, since it seems that i didn't fully
understand it either.
> I'm resistant to adding this because it opens up a lot of complications (like
> how to handle should_not, for one), so I'd prefer to see some experience with
> it first.
#should_not just waits the time of specified timeout and fails if the
should_not is not satisfied before... if it is satisfied before
timeout, then matcher succeeds.
For example:
h = {:special => true}
Thread.new {sleep 0.5; h.delete :special}
h.should_not have_key(:special).in(1)
h = {:special => true}
expect {
h.should_not have_key(:special).in(0.1)
}.to raise_error
Did i get it wrong in here and should these situations behave somehow
differently instead?
How is currently situations like these handled with RSpec or is
everything asynchronous specc-ed with using mocks?
> Have you looked at writing an extension gem that adds this behavior? I think
> that would be a great way to go with this, because users could just add a gem
> dependency and have access to it, and if it became widely used we could
> always talk about merging it later.
I haven't planned to just release a gem with this minor extension.
Does it really make sense to introduce a completely new gem, which
just adds this functionality?
> WDYT?
>
> David
Jarmo
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
