Migrating Selenium Scripts from Firefox to Chrome
Dec 14, 2017 - Your AppNeta Monitoring Points are going to be upgraded so that your Selenium scripts for Experience monitoring will run using Google Chrome! Previously they were run using Firefox, but Chrome is by far the most common browser used on the internet so now your synthetic web applications will even better represent live transactions.
Chrome is available now for you to try out! Read more.
In most cases your Selenium scripts for Experience monitoring will continue to run without change. (There are no changes at all for AppNeta synthetic scripts, which will continue to execute on their existing browser engine.) In some cases, based on how your Selenium scripts were written, some minor modifications may be required to get the most out of Chrome.
In the unlikely event that your Firefox Selenium scripts do not execute as expected under Chrome, here are some areas to pay attention to:
Timing—In general, performance of the Chrome browser implementation is faster than that of the Firefox implementation. This may introduce some subtle differences in workflow timing where scripts complete faster than they did historically. If you have finely tuned your alert profiles for the timings you expected from Firefox we recommend you let Chrome run for a few days to establish a new performance baseline and update your alert profiles accordingly.
If your workflow has designed pauses it may be necessary to modify it to accommodate the different timing. Synthetic transactions execute as fast as possible, and that may be too fast for some applications. You can review the Selenium pause, waitFor*, or *AndWait commands to understand the options for encoding a delay into your script.
Ambiguous target selectors—Where the target selector for a Selenium command matches multiple targets on a page, the target Chrome matches may differ from the one Firefox would match. It is a best practice to use non-ambiguous target selectors (whether using id, link name, XPath, etc.) to make sure your script is the most resilient to minor changes in your monitored applications.
AndWait command variants—Many Selenium commands have “AndWait” variants which will wait for a new page to load, and will fail if the page does not load within a timeout period. For example, there is the clickAndWait variant of click. Under the Firefox implementation, these commands would not always wait for a new page to fully load, and script execution would continue early from the following command. If your script contains AndWait command variants, you may need to revisit their use. For example:
- If the script used an AndWait command followed by waitForPageToLoad or pause commands (effectively to do the wait that the AndWait command may not have reliably done), these commands are probably unnecessary for Chrome. You should consider removing such waitForPageToLoad or pause commands in this situation.
- If the script used an AndWait command where one was not required – for example, if the command action did not result in a page load – you should switch to the non-wait variant of the command. The script may have appeared to execute to completion under Firefox, but may not under Chrome where the AndWait properly waits for page load. Be aware that switching to the non-wait command variant will change the number of milestones in your script in some cases.
- For example, if a clickAndWait was used where there was no associated page load, it should be changed to click so that the script does not wait. The script will now have one fewer milestone, but the removed milestone would not have had any timing data previously, and the timing data of the final milestone will remain consistent from Firefox to Chrome.
If you have any questions, please contact AppNeta Support.