This seems like a really good idea. What I'm currently doing with our AJAX heavy site now feels very overcomplicated.
On Tue, Oct 19, 2010 at 4:03 PM, Jarmo <[email protected]> wrote: > On Tue, Oct 19, 2010 at 9:26 PM, Ethan <[email protected]> wrote: > > It seems like it would be very confusing that a method #not_exists? would > > behave differently than !#exists? (or even need to be defined). I would > > avoid it. This goes back to what I was saying that I think this should > > happen in #initialize rather than in subsequent existence-checking. > > The only thing that would behave differently would be the automatic > waiting. Otherwise it would behave the same so i don't see much of a > problem. Agreed though that it would make the API more complicated and > possibly confusing. I still don't see any advantages of waiting > automatically in #initialize due to the fact as you itself mentioned > later on that you're checking also non-existance of an elements. > > > Implementing waiting versions of any given commonly-used method (and its > > negation, to boot) sounds like it would confuse the API a lot. Given that > > you can use any of those to specify locating a div, checking whether a > > div(:text, some_text).exists? seems preferable to checking > > div.has_text?(some_text) > > You just gave actually a great idea - instead of using wait_until > {div.text == "something"} you could use wait_until {div(:text => > "something").exists?}. This means that #exists? could in theory wait. > I haven't used :text locator in these circumstances at all. This means > also that the only possible automatically waiting methods could be > #exists? and #visible? ... > > > However, another idea is extending rspec with a waiting version of its > > checker. Implement an extension 'should_eventually' (or whatever name, > > that's just off the top of my head), such that: > > div.should_eventually exist > > will run a waiter checking div's existence, and fail if it doesn't come > into > > existence within whatever timeout. You could use this with checking text > or > > classname or whatever without implementing waiting versions of those > > methods. > > I don't know where an extension like that should live, exactly, it seems > > outside the scope of watir itself. but, it's an idea. > > Yup, i also thought about that, but this means that you'd have to > create something like that in every testing framework you'd like to > use. Best would be to have it done at one place - e.g. in Watir. > > > Well, waiting should hopefully not break any compatibility - but > potentially > > slow some things down significantly. For example, an application that > uses > > watir that I work with takes a string and (sometimes) checks if there is > an > > element with that id; if not checks if there is an element with that > name; > > then tries for label with that text. If each of those added a few > seconds, > > that'd be bad. > > My point was that it wouldn't break any backwards incompatibility nor > slow down anything due to the fact that default timeout could be 0 as > it currently practically is. > > I also have used similar solution to you by searching by multiple > locators and allowing strings as a locator, but i've ditched it due to > the possible problems (i wanted to find a different element, but ended > up with something else due to some similar attribute) and actually > making tests harder to read (of course it is a matter of taste). Also > the main reason why i ditched that solution was due to the fact that > it made tests considerably slower (what if you're always searching by > something which is checked last?). That is especially true if some > larger html pages with many elements are used. > > > I don't know. I think it's good functionality to have available, but I'm > > getting more and more hesitant about the idea of changing the default to > > wait any length of time - I do too much checking of maybe-nonexistent > > elements in various places. > > So the only problem would remain if using some solution which allows a > string as a locator and then searching by different locator types. You > could in these methods to set timeout to 0 and after the method is > done, revert the timeout back to it's original value so you wouldn't > have to use wait_until's for "normal" checking for #exists? and > such... > > So, in a light of this e-mail i see having only two additional methods > - #not_exists? and #not_visible?. We could document then in RDoc > properly to point out the differences between !exists? and > not_exists?. I don't see any problems with that. > > With only these two changes it would be also quite easy to convert > your existing test suites to work with a better way and remove many > wait_until's by some global search & replace: > !exists? => not_exists? > not exists? => not_exists? > > !visible? => not_visible? > not visible? => not_visible? > > I think that this is one of the functionalities where we'd have to > make some compromises between adding two (could be little-bit > confusing) methods + making tests a little more cleaner and using > wait_until or something similar pretty heavily every here and there. > I'm starting to like the former. > > Jari, Charley, Bret and anyone else, what are your thoughts on the > subject (it would be better if you answered only if you've used Watir > with AJAX/JavaScript heavy sites where is a need to use wait_until or > something similar). > > Jarmo > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
