6 Answers, 1 is accepted
0
Hi Neeraj,
Cody
The WaitCheckInterval and the WaitForUrl have two very different purposes. Allow me to explain in detail:
- WaitCheckInterval - specifies how often to test if a wait for condition has been meet. Let's say you are waiting for some text to appear on a web page. This value (the default is 500 milliseconds) how often the framework tests the page to see if the text is now there.
- WaitForUrl - specifies how long to wait for the web browser to navigate to a specific URL. This is a timeout value i.e. the maximum amount of time to wait before failing the test.
Thus one value does not override the other. Does that clear it up for you?
Greetings,Cody
the Telerik team
Interested in Agile Testing?
Check out Telerik TV for a recording of
Automated Testing in the Agile Environment
0
Neeraj
Top achievements
Rank 1
Rank 1
answered on 20 Dec 2010, 04:22 PM
Cody - Thanks for the reply. That's very interesting.
Let me ask you one more question - what is the best practice with all these variables to handle an ajax call that refreshes a web page?
Eg: When we choose an account in one of our forms, our webpage is refreshed with some data (an ajax call) - right now we are putting an execution delay in the test step where it occurs - is this the best way to handle this?
If yes - can this variable be overwritten by any global variable right across all the tests?
Any insights on this would be appreciated.
Let me ask you one more question - what is the best practice with all these variables to handle an ajax call that refreshes a web page?
Eg: When we choose an account in one of our forms, our webpage is refreshed with some data (an ajax call) - right now we are putting an execution delay in the test step where it occurs - is this the best way to handle this?
If yes - can this variable be overwritten by any global variable right across all the tests?
Any insights on this would be appreciated.
0
Hello Neeraj,
Regarding AJAX events, it is our recommendation that best practice is to add a Wait.For element to exist or element to be visible. As an example, you know in advance that after the AJAX postback completes the string "Invoice 4452" appears in a certain cell in a grid, that you add a wait for this text to appear.
If what will come back will be variable/random, then we can implement a very similar approach in code. The idea will be to wait for the data to change in some location on the page, or wait for the number of rows contained in a grid to change or something like this. Unfortunately our standard verification steps cannot detect just a change. They're setup to watch for a specific value or property to be present on an element, not for just a change in the value or property.
By taking this approach instead you will avoid fixed delays in your test automation. Instead the test will wait just long enough for the value or property to appear and then it will resume without delay.
Cody
First let me address your question regarding global settings. There are just a few settings that can be set globally, but must be done in a coded step. These include:
- WaitCheckInterval - Specifies how often to test to see if a condition has been met.
- ExecuteCommandTimeout - Specifies how long to wait for a command sent to the browser to complete. The test will fail if the time exceeds this value.
- ClientReadyTimeout - Specifies the amount of time to wait for the browser to return to a ready state (finish reloading the web page) after sending it an action command e.g. a click.
- SilverlightConnectTimeout - Specifies how long to wait
- SimulatedMouseMoveSpeed
Regarding AJAX events, it is our recommendation that best practice is to add a Wait.For element to exist or element to be visible. As an example, you know in advance that after the AJAX postback completes the string "Invoice 4452" appears in a certain cell in a grid, that you add a wait for this text to appear.
If what will come back will be variable/random, then we can implement a very similar approach in code. The idea will be to wait for the data to change in some location on the page, or wait for the number of rows contained in a grid to change or something like this. Unfortunately our standard verification steps cannot detect just a change. They're setup to watch for a specific value or property to be present on an element, not for just a change in the value or property.
By taking this approach instead you will avoid fixed delays in your test automation. Instead the test will wait just long enough for the value or property to appear and then it will resume without delay.
Cody
the Telerik team
Interested in Agile Testing?
Check out Telerik TV for a recording of
Automated Testing in the Agile Environment
0
Susan
Top achievements
Rank 1
Rank 1
answered on 17 Feb 2011, 07:08 PM
I apologize for resurrecting an older thread, but I'm very curious about this statement:
"If what will come back will be variable/random, then we can implement a very similar approach in code. The idea will be to wait for the data to change in some location on the page, or wait for the number of rows contained in a grid to change or something like this."
Is there a demo or a code snippet demonstrating this technique anywhere? Because this would fit my situation perfectly - I have a Grid inside a Ajax Panel (with a loading panel that displays while changing pages). The grid displays property search results, and any test steps that come immediately after a page change (next page or a page index) fail. I am able to extract any combination of testable data from the grid when it loads (for example, the InnerText of the GridDataItem representing the first row in the Grid). After reading the last post here, I've been trying in vain to create a Wait.For condition that would wait until the next page in the grid loads, testing the inner text of that first row.
Can you point me in the right direction to accomplish what you mention above? Thank you.
"If what will come back will be variable/random, then we can implement a very similar approach in code. The idea will be to wait for the data to change in some location on the page, or wait for the number of rows contained in a grid to change or something like this."
Is there a demo or a code snippet demonstrating this technique anywhere? Because this would fit my situation perfectly - I have a Grid inside a Ajax Panel (with a loading panel that displays while changing pages). The grid displays property search results, and any test steps that come immediately after a page change (next page or a page index) fail. I am able to extract any combination of testable data from the grid when it loads (for example, the InnerText of the GridDataItem representing the first row in the Grid). After reading the last post here, I've been trying in vain to create a Wait.For condition that would wait until the next page in the grid loads, testing the inner text of that first row.
Can you point me in the right direction to accomplish what you mention above? Thank you.
0
Hello Steve,
I've attached an example test.
Do you know what's going to be on the page you want to be on? If so you can record a simple "WaitFor text content is..." on a GridDataItem in order to make sure you're on that page (step 3 in the test).
Other than that you can just you the GridPager to Verify the Page Index (screenshot 1 and step 4 in the test).
Let me know if you're having trouble getting this to work!
Best wishes,
I've attached an example test.
Do you know what's going to be on the page you want to be on? If so you can record a simple "WaitFor text content is..." on a GridDataItem in order to make sure you're on that page (step 3 in the test).
Other than that you can just you the GridPager to Verify the Page Index (screenshot 1 and step 4 in the test).
Let me know if you're having trouble getting this to work!
Best wishes,
Stoich
the Telerik team
Registration for Q1 2011 What’s New Webinar Week is now open. Mark your calendar for the week starting March 21st and book your seat for a walk through all the exciting stuff we ship with the new release!
0
Neeraj
Top achievements
Rank 1
Rank 1
answered on 07 Mar 2011, 10:51 PM
Steve - I am not sure if you found your answer. I just want to share one thing that we found on our end to consistently run these tests without any timing issues.
One of the property that is available in each test step is WaitOnElementsTimeout. We believe if we increase the time for this (eg: 15 secs) , the WebUI test runner waits for upto 15 secs until it passes the condition of the step. Eg: If we click on a panel a refresh of the screen happens - If we put WaitOnElementTimeout for 15 secs, the refresh happens in 5 secs then the execution passes this step after 5 secs. We made some changes on our tests with this property and we are seeing a very good success rate.
Hope this helps !!
One of the property that is available in each test step is WaitOnElementsTimeout. We believe if we increase the time for this (eg: 15 secs) , the WebUI test runner waits for upto 15 secs until it passes the condition of the step. Eg: If we click on a panel a refresh of the screen happens - If we put WaitOnElementTimeout for 15 secs, the refresh happens in 5 secs then the execution passes this step after 5 secs. We made some changes on our tests with this property and we are seeing a very good success rate.
Hope this helps !!