25. Appendix 7: Webdriver Timeouts

25.1. Introduction

When using Vitaq for testing webpages and mobile apps there is a chain of services running. In the case of web testing Vitaq is communicating with the client (vitaq_client or scriptworks_vitaq_client), which in turn communicates with the webdriver (selenium webdriver or webdriverIO), which communicates with the selenium stand alone server and then the browser. At each stage there is the potential for a service down the chain to stop responding. If this happens then to avoid the whole chain upstream waiting forever for a response the tools use timeouts.

Choosing the values for timeouts is difficult. If too short a timeout is chosen, then an element in the chain may timeout while the web page is behaving correctly, but taking some time to render or move to the desired state. If too long a timeout is chosen , then when an error occurs a lot of time would be wasted in automated testing waiting for the timeout to trigger. The only reliable way is for the test automation engineer to select an appropriate set of timeouts with knowledge of the application being tested.

25.2. Webdriver timeouts

The main set of timeouts that are available are the webdriver timeouts. Official documentation can be found here for the selenium webdriver timeouts:

https://www.selenium.dev/selenium/docs/api/javascript/module/selenium-webdriver/lib/webdriver_exports_Options.html#setTimeouts

And here for the webdriver IO timeouts:

https://webdriver.io/docs/api/browser/setTimeout.html

There are three timeouts that are specified:

1. Implicit – although the same name is used by both Selenium webdriver and webdriver IO , it seems that the definition is different between them. In the case of selenium webdriver, implicit specifies the total amount of time available for a locator strategy to find an element. Whereas, in the case of WebdriverIO, the implicit timeout is the time between retries of the locator strategy and the timeout for locating the element which is defined for each command. The reader is referred to online resources for further details.

In order to avoid confusion between these two timeouts, the clients uses different command line options for each.

For Selenium webdriver, the command line option is “implicit” and defaults to 5000 milliseconds, meaning that after 5000 ms, the webdriver will stop looking for the element and timeout.

For Webdriver IO, the command line option is “implicit_wdio” and defaults to 1000 milliseconds, meaning that the webdriver will wait for 1000 ms between attempts to apply the locator strategy.

2. Pageload – this is the same between Selenium webdriver and Webdriver IO and as the name suggests is a timeout for the page to load. The clients use a command line option called “pageload” and defaults to 60000 milliseconds (1 minute) for page loading.

3. Script – this also is the same between Selenium webdriver and Webdriver IO and is a timeout for a script to execute. These are scripts that are executed with specific commands and the user should look at the online documentation for more details. The clients use a command line option called “script” and defaultsto 30000 milliseconds.

25.3. Client timeout

There is a fourth timeout available which is defined within the clients. This timeout is the time taken for a single test action to complete. It is provided to handle the case where the webdriver may stop responding. It is set via the command line option “testActionTimeout”, which defaults to 60 seconds (note this is set in seconds and not milliseconds). This means that if after 60 seconds the test action script has not completed, then the client will timeout and close the connection to the webdriver. The user should set this to a value that is greater than any of the test action scripts will run for. It also needs to be greater than any of the webdriver timeouts, this so the webdriver timeouts can run to their full extent before the client times out. The user will note that it defaults to the same value as the default pageload timeout. If pageload timeouts are an issue one or other should be adjusted to suit the application.

25.4. Stopping Vitaq runs

With such a long chain of services communicating with one another, there are many ways a user could choose to stop the automation. The best way to stop the automation is to use the “stop” button in the Vitaq UI. This sends a command which will stop each of the elements of the chain. Stopping one or more of the services may lead to a confused state. For example if the browser window opened by the selenium stand alone server is closed, then the selenium server will attempt to re-start the browser and at the same time the webdriver and the client may timeout.