In this section:

Introduction

SOAtest uses Selenium WebDriver for web testing. Selenium WebDriver makes direct calls to the browser's WebDriver, leveraging the browser's native support for automation. SOAtest 2020.1 and older also shipped with the Parasoft legacy engine, which supported a Parasoft-specific implementation for playing back browser scenarios. The Parasoft legacy engine was removed in SOAtest, Virtualize, and CTP 2020.2. If you upgraded from an older version of SOAtest, web scenarios recorded and configured to play back using the Parasoft legacy engine will still work in many cases. Some tests, however, may fail and need to be updated. This topic provides information about using the Selenium WebDriver engine after upgrading from a version of SOAtest that used the Parasoft legacy engine.

Upgrade Notes

This section describes changes associated with using Selenium WebDriver engine.    

General Notes

• "Wait for Asynchronous Requests" wait conditions are not supported and should be replaced with "Wait for Interval without Traffic" wait conditions. Make the interval long enough for the asynchronous request to occur.
• The __No_Name_:# window format identifiers is not supported. Re-run scenarios recorded with this format and open them. Use the drop-down menu to specify the correct window. You can use the window name or window index to identify a window.

Obsolete Browser Commands 

The following commands were available in the Parasoft legacy engine and have either been replaced or made obsolete by the Selenium WebDriver.

Interacting with Hidden Elements

The legacy engine was able to interact with hidden elements. The Selenium WebDriver engine, however, attempts to simulate real users and only interacts with visible elements. If your legacy scenario interacts with hidden elements, add intermediary steps to reveal hidden elements so that you can successfully run scenarios with hidden elements. The most common way of doing this is to click an element that makes the hidden element become visible.

An error message such as Unable to perform user action: Element is not currently visible might indicate that migration is required (it could also indicate that the application is not behaving as expected). 

Validations that Use Relative URLs

The legacy engine extracted relative path when validating on href or src attributes. The Selenium WebDriver engine extracts the absolute path. For example, assume that you have browser contents with <a href=”xyz.html”>  on the http://localhost:8080 domain. The validations will be http://localhost:8080/sample/xyz.html (the absolute path).

An error message such as Validation failed for property "href": Actual value found on the page "http://localhost:8080/sample/xyz.html" must be equal to expected value "xyz.html" indicates that migration is required. 

Update the expected value if you receive this message, e.g.:

Script Dialog Actions

The following actions are not supported:

• Answeronnextprompt
• Assertalert
• Assertprompt
• Assertconfirmation
• Choosecancelonnextconfirmation

Use the following equivalent Selenium commands to perform the same actions:

• Update Alerts: Use Accept Script Dialog to replace Assertalert.
• Update Confirms: Depending on whether the user action is to click OK or Cancel in the dialog, use Accept Script Dialog or Dismiss Script Dialog to replace Assertconfirmation. Choosecancelonnextconfirmation has been removed and is no longer necessary.
• Update Prompts: Depending on whether the user action is to click OK or Cancel in the dialog, use Accept Script Dialog or Dismiss Script Dialog to replace Assertprompt and Answeronnextprompt user actions.
• Update Attached/Actions: Any Browser Validation tools attached to an action triggering the alert (e.g., Click ‘alert’) should be attached to the Accept Script Dialog or Dismiss Script Dialog action following the action that triggers the alert.

Known Selenium Bugs and Issues

• Chrome 28+ and Selenium's chromedriver is not compatible with RHEL/!CentOS 6.x. CentOS 7.0 (64-bit) works—although there is a warning reported. This warning can be disabled from the command line with setsebool -P unconfined_chrome_sandbox_transition 0 
• Selenium WebDriver randomly fails to accept the script dialogs. This occurs when a test tries to open a dialog and the "Wait for Script Dialog" is reporting error that script dialog does not exist during the specified timeout (by default 10 seconds). The issue can be solved by increasing the wait time. See https://groups.google.com/forum/#!topic/selenium-developer-activity/It-RyMNBrpw for details.
• In Chrome, Selenium cannot interact with onBeforeUnload dialogs that open due to a Navigate, Go Back, or Go Forward action. See https://code.google.com/p/chromedriver/issues/detail?id=29 for details.
• In Chrome and Internet Explorer, Selenium cannot interact with onBeforeUnload dialogs that open when calling "Close" on the only browser window.
  • Chrome: See https://code.google.com/p/chromedriver/issues/detail?id=901 for details.
  • Internet Explorer: See https://code.google.com/p/selenium/issues/detail?id=7895 for details.
• Selenium WebDriver fails to accept an alert that is opened on a new window. See https://code.google.com/p/selenium/issues/detail?id=7807 for details.
• Modal dialogs (those opened using the JavaScript function "showModalDialog") are not supported for Chrome. Web applications that rely on this functionality should use Internet Explorer or Firefox. 
• For the "click" user action, key modifiers ("Shift," "Ctrl," and "Alt") are supported only in Chrome due to an issue in Selenium WebDriver. See https://code.google.com/p/selenium/issues/detail?id=4385 for details. 
• When multiple windows are opened by one user action, the Selenium WebDriver can return a wrong order of window handlers for Chrome and Internet Explorer. This can happen only in the case of unnamed windows. The workaround is to use named windows. 
• Cannot click on area elements in Internet Explorer. See https://code.google.com/p/selenium/issues/detail?id=2354 for details. 
• In Internet Explorer, if an application overrides the default "fireEvent" implementation on an element with a new implementation, Selenium will trigger the new implementation when performing actions on that element. This differs from default browser behavior, where the default "fireEvent" implementation is called even when the "fireEvent" method is changed by a web application.
• Selenium does not support playing back scenarios in headless mode. If headless mode is selected, the scenarios will still play back in visible mode.

Manually Upgrading to a New Version of Selenium WebDriver

You can upgrade SOAtest’s Selenium WebDriver version before it is available in a new SOAtest release. Changing to a different version of Selenium WebDriver from the version shipped with SOAtest is not officially supported or tested by Parasoft. As a result, you may encounter incompatibilities when running the newer version of Selenium WebDriver.

To upgrade, you need to:

1. Upgrade the Selenium client, which also upgrades WebDriver support for Firefox playback. This step is required, regardless of the browser(s) you want WebDriver to use for playback. For details, see Upgrading Selenium Client Libraries (Includes Updating WebDriver Support for Firefox).
2. Upgrade WebDriver’s playback support for the desired browser(s)—Chrome and/or Internet Explorer. See the following sections:

Running Selenium WebDriver Browser Scenarios Using soatestcli on Linux

When SOAtest runs a browser test, it starts the browser used for testing (e.g., Firefox or Chrome) as a separate process. On Linux, the browser process must connect to an X display. When running SOAtest from the UI, this works seamlessly because the browser uses the same display as SOAtest. When running soatestcli through an automated job or in a terminal not connected to a physical display, extra setup is required for browser scenarios that use the Selenium WebDriver playback engine. 

Start a Virtual X Server (Xvfb) to Create a Display

The Selenium engine does not automatically use X virtual framebuffer (Xvfb), but it can be configured manually. Xvfb enables you, for example, to run a Selenium browser scenario in an automated soatestcli job on Linux without a display. Install Xvfb on the machine where soatestcli will run. (Alternatively, you can use the Xvfb_Linux that is packaged with SOAtest, but you may need to experiment with options to get these working. See Getting Xvfb working independently of SOAtest for more information.)

The easiest way to use Xvfb is to start a single process that will be used by all SOAtest runs. To do this:

1. Log in to the machine where soatestcli will run (w.g., by ssh).

2. Run a command such as the following:
   $ nohup Xvfb :99 > /dev/null 2>&1 &

This starts Xvfb on display :99.  All logging information is discarded (sent to /dev/null). The "nohup" command ensures that the Xvfb process will continue running after you log out.

Note that each time you restart the machine, you will need to remember to start another Xvfb process before any soatestcli runs. If you want to avoid this, you can use scripting to start and stop Xvfb as needed.

Set the DISPLAY Environment Variable

The browser uses the DISPLAY environment variable to determine what X display to use.

How to set the environment variable will depend on how you have configured your automated jobs to run. What is important is that the DISPLAY variable is set to the same value that you use when starting Xvfb. For the above example, that value is ":99".

If you have created a shell script—or if you need to run soatestcli on the server on an ad-hoc basis—then you can directly set the variable in the script.  For example, if using bash: 

$ DISPLAY=:99 soatestcli ...options...

Or:

$ export DISPLAY=:99
$ soatestcli ...options...

If you are using Jenkins to run automated jobs, then you can set the DISPLAY variable for your jobs by configuring the environment of a Jenkins node. (Be aware that this will set the variable for all jobs that run on the node, not only your SOAtest jobs.) To do this:

1. Browse to the Jenkins web page.
2. Log in.
3. Click the Jenkins node on which soatestcli will run.
4. Click to configure the node.
5. In the "Node Properties" section, add an environment variable with the name "DISPLAY" and the desired value (e.g., ":99").