With the new release of Selenium late last fall, it was viewed as a saving grace to many test teams.
The launch of the upgrade came with the bonuses and testing tools most had been waiting for, but unfortunately there was still a kink in Selenium’s armor: the Firefox browser.
For those who downloaded the WebDriver APIs that were released with Selenium 2.0, upgrading to Selenium 3.0 was a simple transition; the code was essentially the same as the last 2.x release.
However, Firefox browser initialization became the most pronounced problem among the Selenium testers: the two applications still didn’t work together.
Fortunately, going forward, Selenium will support Marionette, the automation driver for Mozilla’s Gecko engine— GeckoDriver. This next generation of FirefoxDriver is nearing its completion.
First, this article will explain what GeckoDriver is, and how to use Firefox GeckoDriver in Selenium 3.0. Then, we’ll go over potential risks when using RC APIs. Lastly, we’ll answer questions regarding risks and challenges such as selenium RC, APIs, and Mobile testing.
GeckoDriver – a new WebDriver from Mozilla
Gecko is a web browser engine used in many applications developed by Mozilla Foundation and the Mozilla Corporation.
This executable starts a server on your system and all your WebDriver calls are expected to be communicated to this server. It would translate your calls into the Marionette protocol and let the automation driver interact with the browser.
There are three different ways to use GeckoDriver with Selenium 3.
- You can set system properties in the test (to run tests on your local machine).
- You can set system properties by Environment Variable. You would just go to Environment Variables then add the path of the GeckoDriver to variable name Path under the System variables. After setting the path, it’s not necessary to set the system property every time you create an instance of FireFoxDriver.
- Lastly, you can use the setting up Browser Desired Capabilities (in case you would like to run tests on your remote machine– a node of a Selenium Grid).
Selenium Remote Control (RC) has become legacy
In the new version, the Selenium Core is removed and the RC APIs have become legacy. However, you would never mind about them if you already changed your tests from Selenium RC to WebDriver or if you are developing your tests by WebDriver APIs.
Though Selenium 3.0 still has RC APIs, it has been moved to a “legacy” package. Nevertheless, the original code powering Selenium RC has been replaced with the one backed by WebDriver APIs, which is also contained in the legacy package.
In case your tests are still powered by RC, there would be some common problems when running with Selenium 3.0:
- Clicking and typing is more complete
- WaitForPageToLoad returns too soon
- Finding by Xpath or CSS selectors doesn’t always work, but it does in Selenium 1
- There is no Browserbot
Moreover, Selenium RC server would be replaced by Selenium 3 server which would be command line compatible.
Good news! Selenium WebDriver APIs have no major changes
Java binding structure has been changed
There are practically no changes for other binding structures except Java. The Java Selenium APIs are broken up into three packages as follows:
- Selenium-java: contains the WebDriver classes
- Selenium 3 server: a lightweight, command line compatible remote server
- Legacy RC: contains the old selenium client side classes, WebDriverBackedSelenium, and the remote end point for Se3 server.
The underlying JDK has been upgraded
Selenium 3.0 is powered by Java 8. This would be nothing if you are compiling and running an old test on the new Selenium version. However, if you developed a sophisticated framework, you would spend more effort to migrate your framework to the latest JDK.
Still no support for mobile
There is no change in terms of additional features for mobile testing. Selenium is targeting to have new features specific to mobile in the next version, 4.0. For mobile users, the Selenium 3.0 will be hosting a suite of tests to facilitate interoperability between the many different projects available (i.e. Appium, IOS-Driver, Selendroid, etc.) that are extending the WebDriver API to also cope with mobile.
W3C WebDriver is coming
W3C specification for browser automation is in progress, based on the Open Source WebDriver. The draft version of the standard could be found here. WebDriver’s API is incredibly simple and concise by design. Furthermore, the API is designed to be ubiquitous in its application.
There would be two core concepts in the WebDriver specification:
- WebDriver represents the browser
- WebElement represents a DOM element
Since W3C WebDriver specification is in progress, and they are focusing on defining WebDriver as-is, API will remain mostly unchanged. However, you would expect some provisioning changes according to the Future of Selenium:
- Wire protocol (SPI) changes
This will make existing 2.x client bindings incompatible!
API will remain mostly unchanged
- Actions, multi-actions, parallel actions, touch
- Errors will be more consistent
- Full page screenshots will go away
- maximize/resize window
- <input type=file multiple>
- switchToWindow will only take handle as argument
- Stop conflating attributes and properties in getElementAttribute
Selenium 3.0 has been released with no major changes from the previous version. It could be considered as a stage in preparation for the W3C standard. It simply removed the non-standard APIs and encourages Selenium users to move to standard-coming WebDriver. If you are still in the old world of Selenium, you have to immediately change. Otherwise, it’s best to stay calm and wait for the standard.
Thong Nguyen joined LogiGear in 2009 as a software developer and got familiar with test automation. Thong currently is LogiGear’s lead in researching; he is responsible for setting up the innovation of TestArchitect, a leading tool in test automation. Nevertheless, Thong has not only joined many internal technical seminars, but has taught at the University of Sciences as an instructor in testing domain.
Minh Ngo started his testing journey in 2008 as a Technical Engineer for Personal Navigation Devices at TomTom International B.V, Netherlands and joined LogiGear in 2012 as a Test Manager of TestArchitect product. He oversees LogiGear’s TCoE as Lead— responsibilities include R&D for automation, best practices, and testing services.