Still remember the first post of our article series? It talked about how you can run XLT test cases in different browsers. If you’ve done so already, you might have noticed that the behavior of test cases developed in Script Developer sometimes differs depending on the WebDriver you’ve chosen. This article is meant to help you resolve such issues.

First of all, what’s the reason for these inconsistencies? Web browsers differ in their characteristics, such as site representation or functionality, due to their varying support of web technologies like CSS or HTML. You probably know that there is much more we could list, but the major point is pretty obvious already: using WebDrivers for test case execution calls real browser instances. Logically, you’re faced with the same differences as in real web browsers. It’s impossible to achieve a completely consistent web browser behavior; yet you can design your test case as outlined below to at least reduce the differences.

Time: Enlarging time properties can prevent timing problems with dynamically loaded content, like iframes or page content added with JavaScript. Script Developer lets you set an ‘Implicit Wait Timeout’. It allows to specify how long the test should wait for a command to fail while trying to find elements.

A corresponding setting is also available for WebDriver test execution in the XLT properties files. The following property defines the WebDriver’s implicit wait timeout used when finding elements:

Another way to control the execution speed is to set the action think time, that is a delay between the execution of two subsequent actions. Note that this property is only relevant when using the XltDriver.

Incomplete database processes or unfinished AJAX operations may also cause certain problems. If you encounter such problems with the XltDriver, check whether the following property is set to default:

This is the time (in ms) to wait for JavaScript background jobs to finish.
When this time has elapsed, all pending jobs will be removed. Default value is 0, if not set. If set to -1, the engine will neither wait for running jobs to finish nor remove pending jobs. Note that the other WebDrivers don’t have this property. That’s why you should prevent possible problems by taking care of them when you actually design your tests with Script Developer. waitFor… commands are a very good way to achieve this. They’ve been developed for XLT and wait much longer than other assertions. You can configure their waiting time, or command timeout, in both the Script Developer settings and in the XLT properties for WebDriver test execution:

Make sure to use waitFor… commands for dynamically loaded content, even if, for instance, an assert… command appears to be sufficient in Script Developer. If you want the test execution to wait for a specific time period, you can also define a pause. Avoid using …andWait commands for dynamically loaded content because these commands will wait for a new page load which will not happen when content is loaded dynamically.

CSS/link selectors: Using CSS-selectors may be comfortable and is also supported by Script Developer. Keep in mind, though, that the CSS interpretation is different for each WebDriver. For example, the CSS text-transform feature modifies the text specified in HTML. A text validation might fail if this CSS feature is supported in one browser only. Link locators may also cause problems in this context. For now, it’s best for you to avoid these selection strategies when creating test cases in Script Developer and instead use XPath referencing where possible.

Redundant clicks: Text and number validation in forms is often done using the onBlur event that is fired when you leave the input field by clicking somewhere outside the form.

Imagine you are testing input field validation. A JavaScript function displays an error message onBlur, you leave a field with an invalid input, and click somewher else so that the onBlur event is fired. If this click hits the submit button, Script Developer and the XltDriver will forward to the next page whereas WebDrivers need two clicks, one for firing the event and another for submitting the page. A helpful workaround is the seemingly redundant click on a static page element to force the JavaScript event right before submitting. This also helps in case of hiding UI-elements, that mask other elements. This scenario is a known issue in ChromeDriver.

Conclusion:

Being third-party products, WebDrivers aren’t consistent and never will be. Nevertheless, modifying certain XLT properties as outlined above may help you cope with these differences and reduce them whenever you want to go for multiple browsers.