Timeout is an important parameter in test automation that impacts the reliability and responsiveness of automated test executions. In accelQ, this parameter is managed at multiple layers to accommodate the need for responsiveness. This article highlights the nuances of this fine grain control and explains how these settings impact test execution.
acccelQ comes pre-configured with optimal timeout settings, while providing an ability to control in case there is a specific need.
Page and Element wait times
This configuration is controlled during test execution in the Run modal. Default values are 60 sec and 30 sec respectively. Page timeout is the amount of time, test execution will wait for a page to load. This is used in conjunction with the Synch element setup for a Context. Similarly, element timeout is the amount of time, test execution will wait for an element to be ready to function on.
This is the most common setting you would tune according to your need.
Note: Commands that enquire readiness of an element such as is-exists, is-enabled etc. do not wait for the element timeout. They respond immediately.
Runtime Selenium Grid timeout configuration
In addition to the functional timeout settings you specify with the page and element timeouts, there are additional infrastructure level settings you can fine tune. This goes as part of Selenium grid setup.
Note: This is typically an admin level tasks when the execution environment is shared for the team.
"timeout" : 300 (300 seconds is default) This is set in the hub config json file. Hub automatically releases a node that hasn't received any requests for more than the specified number of seconds. After this time, the node will be released for another test in the queue. This helps to clear client crashes without manual intervention. To remove the timeout completely, specify -timeout 0 and the hub will never release the node.
Note: This timeout kicks in when no browser interaction command is sent to the node for the specified time. If your test logic involves hard coded wait for longer duration, ensure that this setting is more than the possible sleep in the logic.
Max sessions on the Node
"maxSession" : 5 (5 is default) The maximum number of browsers (of all types, inclusive) that can run in parallel on the given node. This is different from the maxInstance, which limits the number of browsers of a specific type that can be opened at a time on a given node. maxInstances can be controlled separately at a browser-type level.
Browser Timeout on Node
"browserTimeout" : 300 The timeout in seconds that the node waits for the Browser to respond before it is reclaimed. After this time, the node will be released for another test in the queue.
Note: This timeout should be at least equal to or more than the timeout you setup for the Page and Element timeout values.