On Apr 16, 2011, at 4:56 PM, Jarmo Pertman wrote:
> Hello!
>
> I've just added a new cool matcher #in into my framework WatirSplash
> and thought that this could be integrated into RSpec directly actually
> if there's any interest.
>
> WatirSplash uses Watir (or Watir-like) frameworks for testing web
> pages via browser. If you're not familiar with it then here is a short
> example how you had to test ajax-heavy application before:
>
> browser.link(:id => "someid").click
> # let's wait up to 5 seconds for div to become visible
> browser.wait_until(5) {browser.div(:id => "otherid").visible?}
>
> It was quite cumbersome and i thought about adding and #in matcher to
> all matchers so i can do something like this instead:
> # clicking the link changed div's text from "before" to "after" in a
> maximum of 2 seconds
> expect {
> link.click
> }.to change {div.text}.from("before").to("after").in(2)
>
> # clicking link makes div as present in a maximum of 2 seconds
> link.click
> div.should be_present.in(2)
>
> # clicking link makes div as visible in a maximum of 2 seconds
> expect {
> link.click
> }.to make {div.visible?}.in(2)
>
> # use ActiveSupport for adding more meaning to numbers
> require "active_support"
> div.should exist.in(2.minutes)
>
> What do you guys think? Should i add that also into rspec-expectations
> to make spec-ing easier where timing is involved? :)
>
> Jarmo Pertman
I _think_ I like the idea of a timing constraint, but #in seems too general to
me. In fact, ActiveSupport is adding an #in? predicate [1] to Object that lets
you specify that an object is in a collection:
4.in?([2,3,4])
Also, I'm not sure if I'd want this to be a matcher extension or something
built into rspec core. I'm open to ideas though. Anybody else?
[1] https://github.com/rails/rails/pull/258
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
