ExecutionDelay Test List Setting increases execution time by longer than expected

Progress® Telerik® Test Studio® Feedback Portal

Create an account Log In

Back to Feed

Request a Feature Report a Bug

Completed

Last Updated: 07 Jun 2013 15:05 by David

ADMIN

Byron

Created on: 19 Mar 2013 18:57

Type: Feature Request

ExecutionDelay Test List Setting increases execution time by longer than expected

Adding an execution delay from the Test List Settings dialog increases test list execution time by longer than the sum total of the increase in execution delay. For example, a 17-step test with a 200ms execution delay appears to execute approximately 13 seconds slower:

'1/10/2013 4:45:04 PM' - Duration: [0 min: 13 sec: 498 msec]
'1/10/2013 4:52:34 PM' - Duration: [0 min: 26 sec: 506 msec]

This is approximately 764 msec of delay per test step, a difference of 564 msec.

3 comments

David

Posted on: 07 Jun 2013 15:05

Thanks Byron - having the behavior well documented is a good start, but doesn't solve the need to be able to insert short sleeps between actual test steps.  Static delays are a crutch and I hate to use them, but sometimes it is difficult to code a solution to know when it is safe to proceed and having a short delay between test steps would be helpful.

(Sorry for the dislike - first time I have ever used that button!)

ADMIN

Byron

Posted on: 19 Mar 2013 19:02

The problem is, it isn't averaged over all the steps - wait for visible times go way up. In one example there is a call to wait for enable (2 secs) followed immediately by a call to wait for visible on the same element (22 seconds).  Remove the 200 ms delay between steps and the call is almost instantaneous.

'12/21/2012 9:14:00 AM' - Enabling Html Popup Tracker. Test expecting Popups.
'12/21/2012 9:14:00 AM' - Using 'InternetExplorer' version '9.0' as default browser.
'12/21/2012 9:14:02 AM' - 'Pass' : 1. Wait for 'ShowDataButton' is enabled
'12/21/2012 9:14:24 AM' - 'Pass' : 2. Wait for element 'ShowDataButton' 'is' visible.

ADMIN

Byron

Posted on: 19 Mar 2013 19:00

Telerik: Thank you for the feedback. Unfortunately this is how it currently works. 
The confusion comes with the fact, that execution delay is added to each command we send to browser and in some cases a single navigate command for example sends 3 internal commands to browser, to each of which we attach the execution delay, but this is not visible from user.

For example a NavigateTo step sends 3 commands internally:
- Navigate to the specified URL
- Wait until browser is ready
- Refresh Dom tree.

However the fact is that this is confusing and we will document it properly how it works and may implement a change in the algorithm in future to be more clear to user expectations.