The C# web app we are automating for QA testing has been recently
converted to Ajax. Because of it’s asynchronous nature, this has broken
all our test scripts. In order to get them to work, we resorted to
inserting a “sleep()” statement at the beginning of test method in the
test suite, certainly not an ideal solution. So, in the meantime, we’re
stuck with this nonsense:
def test_0001_username()
sleep(2)
@@ie.text_field(:id,‘ctl00_lgnLogin_UserName’).set(‘TEST-5038’)
end
def test_0002_password()
sleep(2)
@@ie.text_field(:id,‘ctl00_lgnLogin_Password’).set(‘passw0rd’)
end
def test_0003_loginButton()
sleep(2)
@@ie.button(:id,‘ctl00_lgnLogin_LoginButton’).click
end
Has anyone else run into this and what was your solution? Thanks!
There is a method on @@ie (i’m assuming Watir usage here) called
something
like #wait_for_response that will block until said execution is done.
Jason
On Feb 5, 12:21 pm, Patrick S. [email protected] wrote:
On one of the forms, one page of a 13-page health risk assessment,
there’s a radiobutton control associated with the question “I know my
blood pressure”. If the user clicks “Yes”, then 2-more textboxes are
displayed where they enter the systolic and diastolic readings. Without
the “sleep()” statements, the textboxes are skippped, after logging an
error stating that the 2-textboxes couldn’t be found. The health risk
assessment was taking about 2.5 mins to complete. With all the sleep()
statements it’s now taking about twice that long, as one would expect.
–
Posted viahttp://www.ruby-forum.com/.
I don’t think it is possible with current WATIR implementation.
You can also try SWExplorerAutomation SWEA (http:\webiussoft.com).
SWEA supports AJAX and eleminates “sleep” statements by monitoring
network traffic and DOM changes - it improves the test automation code
reliability and performance. SWEA is .Net framework, but can be used
from Ruby using RubyCLR.
[email protected] wrote:
I don’t think it is possible with current WATIR implementation.
You can also try SWExplorerAutomation SWEA (http:\webiussoft.com).
SWEA supports AJAX and eleminates “sleep” statements by monitoring
network traffic and DOM changes - it improves the test automation code
reliability and performance. SWEA is .Net framework, but can be used
from Ruby using RubyCLR.
Thanks for the link, but I was hoping for a Ruby solution. I was
thinking that it’s possible to override the
Watir::Element.assert_exists() method. Perhaps go into a loop, on each
iteration of the loop checking @ieController.status for “done” and/or
@ieController.document.readyState == 4. The loop would one run a
specific number of times before exiting and letting Watir throw the
error.
Using the scenario I previously mentioned regarding the blood pressure
radio button and textbox controls… I’ve noticed that when the “I know
my blood pressure” radio button is clicked, the IE status bar briefly
changes to “Please wait…” while Ajax is doing it’s thing. By “doing
it’s thing” I mean updating the page to display 2-textbox controls where
the user inputs the systolic and diastolic reading. After the textboxes
are displayed, the status changes back to “Done”.
Ideas or hints anyone? Thanks!
On Feb 5, 8:56 am, Patrick S. [email protected] wrote:
def test_0001_username()
sleep(2)
@@ie.text_field(:id,‘ctl00_lgnLogin_UserName’).set(‘TEST-5038’)
end
Actually, the latest version (1.5) of Watir does support Ajax. Thus:
def test_0001_username()
Watir::wait_until {@@ie.text_field(:id,
‘ct100_lgnLogin_UserName’).exists?}
@@ie.text_field(:id,‘ctl00_lgnLogin_UserName’).set(‘TEST-5038’)
end
Bret
On Feb 5, 11:53 am, “[email protected]” [email protected]
wrote:
I don’t think it is possible with currentWATIRimplementation.
Why do you say this?
Jason R. wrote:
There is a method on @@ie (i’m assuming Watir usage here) called
something
like #wait_for_response that will block until said execution is done.
Jason
I found a #wait method, no #wait_for_response. I tried that and it
didn’t help.
On one of the forms, one page of a 13-page health risk assessment,
there’s a radiobutton control associated with the question “I know my
blood pressure”. If the user clicks “Yes”, then 2-more textboxes are
displayed where they enter the systolic and diastolic readings. Without
the “sleep()” statements, the textboxes are skippped, after logging an
error stating that the 2-textboxes couldn’t be found. The health risk
assessment was taking about 2.5 mins to complete. With all the sleep()
statements it’s now taking about twice that long, as one would expect.
Bret P. wrote:
On Feb 5, 8:56 am, Patrick S. [email protected] wrote:
def test_0001_username()
sleep(2)
@@ie.text_field(:id,‘ctl00_lgnLogin_UserName’).set(‘TEST-5038’)
end
Actually, the latest version (1.5) of Watir does support Ajax. Thus:
def test_0001_username()
Watir::wait_until {@@ie.text_field(:id,
‘ct100_lgnLogin_UserName’).exists?}
@@ie.text_field(:id,‘ctl00_lgnLogin_UserName’).set(‘TEST-5038’)
end
Bret
Thanks Bret! I’ll give this a go, since the waiting for a status of
“Done” approach doesn’t appear to be working.
Bret P. wrote:
On 2/12/07, Patrick S. [email protected] wrote:
Actually, I’ll need to download v1.5. The most current version on
rubyforge.org is 1.4.1. Where can 1.5 be found?
http://wiki.openqa.org/display/WTR/Development+Builds
But there seems to be a problem with the gem attachments at the
moment…
I don’t know if that has anything to do with the problems I’m still
having. The #wait_until technique isn’t working either. The decision of
the development folks to convert the app to Ajax was made w/o consulting
the QA department as to the possible ramifications. That, on top of the
other problem has forced us to look at other alternatives to Ruby/Watir.
It’s a bloody shame too as we’ve made a sizable investment in the
development of the core code and classes in Ruby.
On 2/13/07, Patrick S. [email protected] wrote:
I don’t know if that has anything to do with the problems I’m still
having. The #wait_until technique isn’t working either. The decision of
the development folks to convert the app to Ajax was made w/o consulting
the QA department as to the possible ramifications. That, on top of the
other problem has forced us to look at other alternatives to Ruby/Watir.
It’s a bloody shame too as we’ve made a sizable investment in the
development of the core code and classes in Ruby.
Don’t give up too soon. We have plenty of Watir users who are using
Watir
1.5 to test Ajax applications.
Bret
Bret P. wrote:
Don’t give up too soon. We have plenty of Watir users who are using
Watir
1.5 to test Ajax applications.
Bret
Any further input or advice would be greatly appreciated! I love the
Ruby/Watir combination. BTW, I don’t what you’ve done with the latest
build of Watir; v1.5.1, but it’s so fast it’s almost frightening! Up
until a couple of days ago I was using v1.4 and running a script w/in
the Komodo IDE was painfully slow. With the latest build, even while
running w/in Komodo, the scripts run as fast as the previous build did
as a standalone script. Outstanding work!
On 2/12/07, Patrick S. [email protected] wrote:
Actually, I’ll need to download v1.5. The most current version on
rubyforge.org is 1.4.1. Where can 1.5 be found?
http://wiki.openqa.org/display/WTR/Development+Builds
But there seems to be a problem with the gem attachments at the
moment…
On Feb 11, 5:56 pm, “Bret P.” [email protected] wrote:
On Feb 5, 11:53 am, “[email protected]” [email protected]
wrote:
I don’t think it is possible with currentWATIRimplementation.
Why do you say this?
The IE automation is very complex problem. The Browser is “alive”. You
can’t lock the browser. You can test for the tag existence and it will
fail on the next line because DOM was changed. SWExplorerAutomation
(SWEA) automates Browser from “inside”. The SWEA engine sits inside IE
and controls all browser activity. WATIR works from outside of IE.
All WATIR calls to IE are marshaled (DCOM). It slows down the
automation performance and makes the automation less reliable.
On Mar 16, 10:50 am, “[email protected]” [email protected]
wrote:
The IE automation is very complex problem. The Browser is “alive”. You
can’t lock the browser. You can test for the tag existence and it will
fail on the next line because DOM was changed. SWExplorerAutomation
(SWEA) automates Browser from “inside”. The SWEA engine sits inside IE
and controls all browser activity.
So SWEA is able to lock the browser? How would you know when to do
this? Is this a good thing? Is this a feature that should be added to
Watir? I don’t understand how a user would use this ability, so i
would appreciate any clarification. Can you show me some code that
does this?
Bret
On Mar 20, 12:28 pm, “Bret P.” [email protected] wrote:
this? Is this a good thing? Is this a feature that should be added toWatir? I don’t understand how a user would use this ability, so i
would appreciate any clarification. Can you show me some code that
does this?
Bret
SWEA doesn’t block the browser - it could be a very bad idea to block
the browser. SWEA monitors all Browser activity in real-time and is
able correctly rebind (reidentify) SWEA controls in the case of the
changes. It makes automation script more reliable and stable. Try to
automate any complex AJAX grid using WATIR (run test 100 times) and
you will see the problem. You will need to place “sleep” statements to
make the script work stable.
On 3/20/07, [email protected] [email protected] wrote:
SWEA doesn’t block the browser - it could be a very bad idea to block
the browser. SWEA monitors all Browser activity in real-time and is
able correctly rebind (reidentify) SWEA controls in the case of the
changes. It makes automation script more reliable and stable. Try to
automate any complex AJAX grid using WATIR (run test 100 times) and
you will see the problem. You will need to place “sleep” statements to
make the script work stable.
Watir scripts don’t need to rebind then there are changes. Watir objects
reference elements of the DOM and these references are stable until the
element no longer exists or a new page is loaded.
I have run many complex scripts multiple times in Watir without problem.
What kinds of problems are you seeing? Are the scripts slowing down? Are
you
getting intermittent failures? Memory leaks? It sounds scary when you
say it
is not stable or reliable, but I’m not getting a clear picture of what
this
looks like to you.
As mentioned earlier in the thread, people using Watir to test Ajax
typically use the “wait_until” method to avoid sleep statements. I would
like to see an example where this wasn’t an option. I agree: sleeps
should
be avoided.
Bret
On Mar 23, 11:19 am, “Bret P.” [email protected] wrote:
automate any complex AJAX grid usingWATIR(run test 100 times)
problem. What kinds of problems are you seeing? Are the scripts
slowing down? Are you getting intermittent failures? Memory leaks? It
sounds scary when you say it is not stable or reliable, but I’m not
getting a clear picture of what this looks like to you.
As mentioned earlier in the thread, people usingWatirto test Ajax
typically use the “wait_until” method to avoid sleep statements. I
would like to see an example where this wasn’t an option. I agree:
sleeps should be avoided.
Bret
I don’t want to say you can’t use WATIR with AJAX, but it can take a
lot of efforts to write the scripts and make them work stable.
Unfortunately, the tests are not we paid for after all.
BTW, is there any WATIR recorder which can record the AJAX scripts?
On 3/20/07, [email protected] [email protected] wrote:
SWEA doesn't block the browser - it could be a very bad idea to
block
the browser. SWEA monitors all Browser activity in real-time and
is
able correctly rebind (reidentify) SWEA controls in the case of
the
changes. It makes automation script more reliable and stable. Try
to
automate any complex AJAX grid using WATIR (run test 100 times)
and
you will see the problem. You will need to place “sleep”
statements to
make the script work stable.
Watir scripts don’t need to rebind then there are changes. Watir
objects reference elements of the DOM and these references are stable
until the element no longer exists or a new page is loaded.
I have run many complex scripts multiple times in Watir without
problem. What kinds of problems are you seeing? Are the scripts
slowing down? Are you getting intermittent failures? Memory leaks? It
sounds scary when you say it is not stable or reliable, but I’m not
getting a clear picture of what this looks like to you.
As mentioned earlier in the thread, people using Watir to test Ajax
typically use the “wait_until” method to avoid sleep statements. I
would like to see an example where this wasn’t an option. I agree:
sleeps should be avoided.
Bret