Build WebDriver Scripts

Build WebDriver Scripts
WebDriver Monitors run selenium XML scripts and collect results for real browser monitoring. You can manually create custom scripts or use the following tools:
Use Katalon Recorder to Create Scripts
The Katalon Recorder is a free browser extension that records browser activity in the selenium XML format. After you record, edit and test the script, you export the XML file and import the file into a WebDriver Monitor.
Follow these steps:
  1. Download and install the Katalon Recorder extension in either Chrome or Firefox.
  2. In the Katalon Recorder, select
    to create a test case within a test suite.
  3. Select
    to start recording the script. The Katalon Recorder disappears and starts recording your steps in the browser.
  4. Select
    to stop recording the script. The test steps appear in an ordered list.
  5. To edit the test steps, select the
    , or
    icons. You can also edit the command, target, and value of an individual test step.
  6. To test the script, select
    . Katalon runs the script in the browser window.
    To prevent browser data from interfering with the script, run the script in incognito (private) mode. WebDriver Monitor runs the XML scripts in incognito (private) mode.
  7. Select
    to save the final script to a human-readable XML format.
    You cannot re-import the XML file back to the Katalon Recorder. Instead, save the Test Suite as an HTML file for future editing.
  8. To upload the XML file to a WebDriver Monitor, open the WebDriver Monitor and select the
    tab select. Select
    on the
    Upload a valid WebDriver script
    field to find the XML file.
You recorded a script and uploaded an XML file to a WebDriver Monitor. For more information, see WebDriver Monitor.
Edit Selenium XMLYou can manually edit Selenium-based XML. Selenium Syntax contains three parameters:
  • Command
    Indicates the action, such as click, double click, open, and refresh.
  • Target
    Represents the target element in the UI, for example, a field, link, or menu.
  • Value
    Specifies the value being selected or entered.
Example: Open Gmail Account
<selenese> <command>open</command> <target><![CDATA[]]></target> <value><![CDATA[]]></value></selenese> </selenese>
Supported Selenium Commands
For the list of supported Selenium commands for WebDriver Monitor, see Supported Selenium Commands.
For more information about Selenium command parameters, see Selenese (Selenium IDE) Commands Reference.
Troubleshoot RBM Scripts
The RBM Script Runs Successfully in Katalon but Fails in WebDriver Monitor
The RBM script runs in Katalon Recorder without errors. After importing the XML file of the script to the WebDriver Monitor, the script fails due to elements not loading.
By default, the Katalon Recorder runs the recorded scripts in one cycle and does not pause for elements to load. Use
commands in the script to pause for the necessary elements.
Also, see WebDriver CLI.
Testing a Script in Katalon Fails
An RBM script fails in Katalon.
Browser data can affect the:  initial test in the Katalon Recorder. Use the incognito (private) mode to test the script in Katalon.
Error Message in WebDriver Monitor
The following message appears after a WebDriver Monitor runs a script: '
Command not specified'.
The WebDriver Monitor may not support a Selenium command in the script. For more information about supported Selenium commands, see Supported Selenium Commands.
Best Practices and Examples to Build WebDriver Scripts
To run the WebDriver monitor, you must have a scenario that is written in the form of an XML script. The easiest way to produce this script is to use a Katalon recorder or Selenium IDE for recording the base of the script.
After the recording, the script must be exported to XML format. See the following example of the script output produced by the Katalon Recorder.
<?xml version="1.0" encoding="UTF-8"?> <TestCase> <selenese> <command>open</command> <target><![CDATA[]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>click</command> <target><![CDATA[name=q]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>type</command> <target><![CDATA[name=q]]></target> <value><![CDATA[app synthetic]]></value> </selenese> <selenese> <command>sendKeys</command> <target><![CDATA[name=q]]></target> <value><![CDATA[${KEY_ENTER}]]></value> </selenese> <selenese> <command>click</command> <target><![CDATA[//div[@id='resultsList']/div/div/div/div[2]/a/span[2]]]></target> <value><![CDATA[]]></value> </selenese> </TestCase>
This scenario runs smoothly in a Katalon Recorder as Katalon uses vendor-specific additions to Selenium WebDriver.
On the other side ASM WebDriver monitor incorporates the Selenium specification only, without Katalon additions. The Selenium scripts may run with errors in the ASM environment though the scripts run without errors in Katalon environment.
Usually, a script that is produced by the automated recording toll must be adjusted manually.
Basic Principles to Adjust the Selenium Script for ASM
You can use some basic principles to adjust the scripts to run smoothly on ASM. See the following principles that can be applied before running the scripts.
Principle 1: Use Assertions
Assertion is the command that fails the step when the condition is not met. Assertions help to ensure the script to execute in a correct way. After login, you can verify that you are not on the login page by executing the following commands:
  • verifyTextPresent
  • verifyTextNotPresent
  • verifyElementPresent
  • verifyElementNotPresent, and others
As an example, perform a login operation and click submit:
<selenese> <command>click</command> <target><![CDATA[//button[@type='submit']]]></target> <value><![CDATA[]]></value> </selenese>
After login, make sure to leave the login page:
<selenese> <command>verifyTextNotPresent</command> <target><![CDATA[Log In]]></target> <value><![CDATA[]]></value> </selenese>
You can modify the first step as the following example:
<selenese> <command>open</command> <target><![CDATA[]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>verifyTextPresent</command> <target><![CDATA[Broadcom]]></target> <value><![CDATA[]]></value> </selenese>
Sometimes you may encounter the issue of text assertion failing during step execution but text presents on the screen. A possible reason for this behavior may be the step with assertion is executed just before the text appears on the page. This issue can be eliminated using the next principle.
Principle 2: Use Wait* Commands
Wait commands evaluate an assertion until it is true or timeout is reached. These commands wait for text or an element to appear and then only execute the next step. See the following list for few wait commands:
  • waitForPageToLoad
  • waitForTextPresent
  • waitForElement
  • clickAndWait and others
In the following example, you can see the command waitForTextPresent in the place of verifyTextPresent. Also instead of click command, clickAndWait command is used.
<selenese> <command>open</command> <target><![CDATA[]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>waitForTextPresent</command> <target><![CDATA[Broadcom]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>clickAndWait</command> <target><![CDATA[name=q]]></target> <value><![CDATA[]]></value> </selenese>
waitForPageToLoad command works only if the browser triggers an entire page reload like opening a new url.
For example, clicking a button on the page may not cause a page reload even if all the information on the page has changed. Page load depends on the technology that the website is written. While execution of the waitForPageToReload command, if the page does not reload then waitForPageToLoad step is evaluated immediately.
Principle 3: Use Wait for the Network Traffic to Stop Option in the Monitor Options
This option resolves many issues with early command execution. Early command execution happens when a command evaluates for the information before appearing on the screen.
Enabling this feature may cause some scripts to fail because of hanging requests.
The following picture is an example of execution flow with the ‘Wait for network traffic to stop‘ option being turned off.
The following picture is an example of execution flow with the ‘Wait for network traffic to stop‘ option being turned on.
Principle 4: Use wait* on the Final Step
Using the last assertion on the final step is important.
When the WebDriver executes the last step, it stops the engine and it interrupts the internet connection. If there is an ongoing HTTP request on the last step, the internet connection is interrupted right after step evaluation and the request fails. This causes an error on the last step.
After making the changes according to the recommendations in the previous steps, the script look like the following code snippet:
<?xml version="1.0" encoding="UTF-8"?> <TestCase> <selenese> <command>open</command> <target><![CDATA[]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>clickAndWait</command> <target><![CDATA[name=q]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>typeAndWait</command> <target><![CDATA[name=q]]></target> <value><![CDATA[app synthetic]]></value> </selenese> <selenese> <command>sendKeys</command> <target><![CDATA[name=q]]></target> <value><![CDATA[${KEY_ENTER}]]></value> </selenese> <selenese> <command>clickAndWait</command> <target><![CDATA[//div[@id='resultsList']/div/div/div/div[2]/a/span[2]]]></target> <value><![CDATA[]]></value> </selenese> <selenese> <command>waitForTextPresent</command> <target><![CDATA[An overview of features and basic use of the product.]]></target> <value><![CDATA[]]></value> </selenese> </TestCase>
After these manipulations, the script executes seamlessly in the ASM WebDriver.