Waiting matcher

[abotalov]

I'd like to propose to add a matcher that will retry given block until it will match all other matchers or time expired.

The matcher is applied to other matchers (like Compound).

Usage examples:

expect { find('#id')[:class] }.to eq('some_class').during(3, every: 0.2)
expect { response.headers }.to include({'Content-type' => 'text/html'}).and include({'Content-Encoding' => 'gzip'}).during(2)

Currently users should use some gem like retriable or some other form of wait_until like:

wait_until(3) { find('#id')[:class] == 'some_class' }
Retriable.retriable :on => Timeout::Error, :tries => 3, :interval => 1 do
  find('#id')[:class] == 'some_class'
end

So error messages don't tell what was the actual value of e.g. find('#id')[:class] in those cases. I think handling this issue at RSpec side instead of adding additional waiting matchers to e.g. Capybara would be a more proper solution since its not webapp-only problem.

Please tell if you think the idea is good or not.

[JonRowe]

In general I don't think RSpec should handle this, Ruby is not, in general, asynchronous so it's up to the code under test to block and return the correct value when dealing with something that is. We also can't guarantee we wouldn't prevent the block from working as we don't know what we're waiting for.

Capybara handles this for you when dealing with browsers because it knows you are waiting for an external process to do something so it is able to safely block and wait for that to finish. It doesn't do it with rack-test for example. If all you want is more detail in the error output for Capybara I'd suggest you suggest it to them!

[JonRowe]

You could also implement this as a gem, or within your own codebase RSpec does allow you to define custom matchers.

[myronmarston]

I agree with @JonRowe: I don't think this belongs in RSpec. You mention it's not a webapp-only problem, but in the ~5 years I've been using RSpec, I've never wanted or needed something like this. I think this could work well as an extension gem, though. If you decide to make one and need some additional extension points to integrate, let us know.

[abotalov]

Currently matchers like eq or include have supports_block_expectations? set to false. So it seems to me adding such a matcher would require at least setting it true and invoking .call if it's a block.

[myronmarston]

You can certainly override supports_block_expectations? in those matchers, but you should be aware of the discussions that went into that design:

• Give users an error when they use a value matcher in a block expectation expression #530
• Unexpected target/handler behavior with respect to blocks #536

[abotalov]

@myronmarston Thanks. I wrote some code (https://github.com/abotalov/waiting_rspec_matchers/blob/master/lib/waiting_rspec_matchers.rb) that just adds new "become_*" rspec matchers. I would be happy if you'll review it.

[myronmarston]

Sounds like you've found something that works for you. That's great.

[bootstraponline]

There's also wait_for via the rspec-wait gem which is cool.