On 13/06/12 10:33 AM, Oscar Rieken wrote:
How would webdriver know the behavior of your application the 2 only
communicate thru the browser.
My naive answer would be "however watir knew before I switched to
watir-webdriver". :) ...
I am guessing that the tests passed in watir and not in watir
webdriver because of the OS and how native events are handled
https://groups.google.com/forum/?fromgroups#!searchin/webdriver/send$20keys$20windows$20wait$20for$20page$20to$20load/webdriver/7K2QWGVNCYo/wqLCoaH6CzYJ
<https://groups.google.com/forum/?fromgroups#%21searchin/webdriver/send$20keys$20windows$20wait$20for$20page$20to$20load/webdriver/7K2QWGVNCYo/wqLCoaH6CzYJ>
That thread is an interesting read, and although it covers much of the
same ground I've covered already before starting this thread, I now have
a notion (even if only a fuzzy one) of how "keyboard and mouse emulation
[done] at the OS, not browser, level" might lead to problems. Is that to
say that with watir, that keyboard/mouse emulation *was* done before at
the browser level? If so, that gives me a satisfactory answer to report
back to my team.
what happens when you try the tests in different browsers?
My recollection is that with firefox, all tests failed for unrelated
reasons. Since I wasn't targetting firefox with the code being tested at
the time, I did not investigate further. I'd have to fall back to an
older version of my tests now to get you that info, and can still do
that if it's relevant, but at this point, I need to switch back to
dealing with other more pressing projects.
Thanks for the clarification. I'll report to my team:
The OS-level mouse/keyboard interface on Windows that webdriver uses
does not provide webdriver with sufficient information about what's
going on for watir-webdriver to really know when the browser is done
responding to a click, whereas watir had a browser-level view of
what was going on and was able to know when the next page was done,
even when the submit was mediated by intervening Javascript code.
Embedding a unique id in each page will allow us to always know if a
new page was displayed. That seems to be the only general solution
available.
Is that a fair charaterization of the problem and its solution?
Thanks,
Ben
If I need to, I will inject something extra into the page and use
one of the approaches listed in the doc above to detect it. It
just seems like some unnecessary extra effort to work around a
regression in watir-webdriver, rather than a step forward. Also,
that doc doesn't specifically address "what if the page looks
exactly the same as it did before?***"
Every time my project suffers delays like this to work out issues
with new tech that not all project members understand, I come
under fire for spending too much time on things that don't seem to
matter to them ("what was wrong with the old technology this
replaces? is the new technology worth the extra effort you're
putting into it?")
Ben
*** In at least one case, the button is called "Refresh" and
retrieves a page of output, rendered in a single <pre>..</pre>
element that may or may not differ from last time, depending on
output generated from a command run on a server contacted by the
script. I had hoped for a generalized and transparent solution
that doesn't care what the resulting page looks like and just
knows "a new page was generated, even if it looked exactly like
the old one".
--
Before posting, please read http://watir.com/support. In short:
search before you ask, be nice.
[email protected] <mailto:[email protected]>
http://groups.google.com/group/watir-general
[email protected]
<mailto:watir-general%[email protected]>
--
Before posting, please read http://watir.com/support. In short: search
before you ask, be nice.
[email protected]
http://groups.google.com/group/watir-general
[email protected]
--
Before posting, please read http://watir.com/support. In short: search before
you ask, be nice.
[email protected]
http://groups.google.com/group/watir-general
[email protected]
