4.6.1. Supported HTML AUTs
Prev | 4.6. Testing HTML AUTs | Next

### 4.6.1. Supported HTML AUTs

AUTs written with the HTML GUI toolkit are supported according to the following points:

- The HTML tests are driven by Selenium. We document which version of Selenium we are currently using as a driver in the release notes. Check the release notes for the current Selenium version and check the Selenium documentation for supported browsers.

- We strongly recommend writing HTML AUTs so that they are conform to the W3C standard. You can check whether your AUT is W3C conform using an online validator: http://validator.w3.org

- We recommend disabling the protected mode in Internet Explorer when testing HTML AUTs. This may be required in Windows 8+ when performing key combinations as a part of the test, but may also be required for other versions and other actions.

- Some of the actions in the concrete toolkit (i.e. which are theoretically valid for all AUT types) may not (yet) be supported. In some cases, this is because the component doesn’t exist as such in HTML AUTs (menu bars for example). In other cases, text components such as tables or lists do not have a concept for dealing with selection as they do in e.g. Swing.

- The autrun option to start AUTs (Section 3.8.4.6, “Starting Java AUTs with the autrun command”) cannot be used for HTML AUTs.

- There is a minor difference in the way that clicks are performed in HTML compared to other supported toolkits. In other toolkits such as Swing, an API is used to simulate actions at the OS level so that the the computer itself can’t distinguish whether it came from a tool or a keyboard. A normal click by a user in a browser would go via the mouse through various layers to the webserver, resulting in a request to that webserver. The clicks in the HTML toolkit are performed by firing DOM events using Javascript therefore bypassing the mouse level. So, although the computer can tell the difference, the webserver can’t.

- HTML AUTs can be tested in single-window or multi-window mode. If your AUT has functions that cause new windows to open, then you should specify this in the AUT configuration. You can then map components from different windows, and also use specific actions to switch windows during your test. Multi-window mode on Internet Explorer is considerably slower than on Firefox – this is a known issue registered at Selenium. There are known issues with AUT starting in multi-window mode on OSX systems for Firefox and on Safari – we do not test these combinations.

Closing HTML AUTs via the close button

- If you close a HTML AUT by closing the browser, the ITE will correctly notice the closure after 5 seconds (configurable) and will remove the AUT from the running AUTs view.

- The mechanism works by polling the AUT, and if it is no longer there after the configured time, the AUT is considered to be stopped.

- If your AUT may sometimes be unreachable for longer than the default 5 seconds, you can change this time by using a process or system property:

  TEST_MAX_AUT_RESPONSE_TIME=<timeInMs>.

- Further information on this is available in this issue:

  http://bugzilla.bredex.de/1391.

Overwriting launcher options now possible

- You can now manually overwrite launcher options for the launchers for autrun, testexec and dbtool.