Ajax woes

[Patrick Spence]

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_fieldid,'ctl00_lgnLogin_UserName').set('TEST-5038')
end

def test_0002_password()
sleep(2)
@@ie.text_fieldid,'ctl00_lgnLogin_Password').set('passw0rd')
end

def test_0003_loginButton()
sleep(2)
@@ie.buttonid,'ctl00_lgnLogin_LoginButton').click
end

Has anyone else run into this and what was your solution? Thanks!

 

[Patrick Spence]

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.

 

[alex_f_il]

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.

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.

 

[Patrick Spence]

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!

 

[Bret Pettichord]

def test_0001_username()
sleep(2)
@@ie.text_fieldid,'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_fieldid,
'ct100_lgnLogin_UserName').exists?}
@@ie.text_fieldid,'ctl00_lgnLogin_UserName').set('TEST-5038')
end

Bret

 

[Bret Pettichord]

I don't think it is possible with currentWATIRimplementation.

Why do you say this?

 

[Patrick Spence]

Actually, the latest version (1.5) of Watir *does* support Ajax. Thus:

def test_0001_username()
Watir::wait_until {@@ie.text_fieldid,
'ct100_lgnLogin_UserName').exists?}
@@ie.text_fieldid,'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.

 

[Patrick Spence]

Thanks Bret! I'll give this a go, since the waiting for a status of
"Done" approach doesn't appear to be working.

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?

Thanks!

 

[Patrick Spence]

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?

Thanks!

I found v1.5.1 at http://www.io.com/~wazmo/blog/, along with suggestion
that those running v1.5 should update to 1.5.1.

 

[Patrick Spence]

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.

 

[Patrick Spence]

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!

 

[alex_f_il]

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.

 

[Bret Pettichord]

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

 

[alex_f_il]

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 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.

 

[Bret Pettichord]

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

 

[alex_f_il]

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 usingWATIR(run test 100 times)
and
you will see the problem. You will need to place "sleep"
statements to
make the script work stable.

Watirscripts 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 inWatirwithout
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?

 

[alex_f_il]

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 usingWATIR(run test 100 times)
and
you will see the problem. You will need to place "sleep"
statements to
make the script work stable.

Watirscripts 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 inWatirwithout
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

Small correction: Watir keeps references to the element proxies. The
DOM elements are located in the IE process. Every check for the
element availability is marshalled between the processes (test script
and IE).

-Alex