Selenium is nowadays an indisputable standard in browser automation. Its architecture is well-known and all popular browsers are supported out of the box. More than that commercial companies provide Selenium infrastructure as a paid service. But is it comfortable to use Selenium server on developer’s machine?
Selenium WebDriver is developed as the successor to Selenium Remote Control (RC). While using Selenium RC, testers have to load web pages by injecting JavaScript functions into a web browser. But Selenium WebDriver takes advantage of the built-in support provided by web browsers to load web pages and drive web browsers. Hence, it becomes easier for web application testers to test a web application across multiple web browsers using a single tool.
Supports Multiple Browsers and Programming Languages
Unlike Selenium IDE, Selenium WebDriver supports several widely used web browsers including Chrome, Firefox and Internet Explorer. The feature makes it easier for testers to execute the same tests against varying web browsers. At the same time, the test automation tool also supports a number of programming languages including Java, PHP, Perl, Ruby, Python, and .NET. It even allows testers to use conditional operations like if-else-then and perform looping while writing test scripts.
Simple Architecture
In addition to overcoming shortcomings of Selenium RC, Selenium WebDriver also features a simple architecture. It controls the web browser from the level of operating system. Hence, the testers can execute test scripts directly without starting the web server. However, the web application testing professionals have to use Selenium commands through the IDE of the specific programming language. They can easily test a web application by combining a web browser and programming language IDE.
Facilitates Real-Time Interaction
While testing a web application, Selenium WebDriver interacts with various page elements in a realistic way. A Selenium testing professional has option to restrict the test automation tool from performing a specific action just like a real user. For instance, developers often prevent users from submitting input by disabling specific text boxes. If a specific test box is disabled for users, Selenium WebDriver will not enter any value through it at the time of testing.
Emulates Real User Actions
In addition to facilitating real-time interaction with the browser, Selenium WebDriver has the capability to emulate certain user actions. It enables users to simulate mouse movements while testing websites. Likewise, the testing professionals can also use specific classes to simulate key press events on keyboard. At the same time, the web application testing tool enables testers to simulate user actions like click and navigation through listeners. The testers can implement WebDriverEventListener methods to perform specific user actions while evaluating the web application.
Accelerates Test Script Execution
Unlike Selenium RC, Selenium WebDriver does not require testers to start the server before executing test scripts. It interacts with the web browsers directly without relying on any intermediary. Also, it controls the web browser through its own engine. The absence of intermediaries makes Selenium IDE much faster than its predecessor. Also, WebDriver accelerates test script execution by giving commands to the web browser directly.
Application Programming Interface (API)
The web application testers even have option to use Selenium WebDriver API as a built-in component of Selenium 2.0. In addition to overcoming the limitations of Selenium-RC API, the WebDriver API also comes with better supports dynamic web pages. The testers can use the API to evaluate the changing page elements without reloading the web page fully. At the same time, they can accelerate dynamic website testing by availing the features provided by the API including file upload or download, pop-ups and dialogs barrier.
This list of disadvantages is far from being complete. But let’s stop at this point and follow a better way to deal with Selenium testing on your development machine.
Introducing Selenoid
Why starting browsers in containers is so useful? And what is the difference between using standard Selenium in Docker containers and using Selenoid?
The main idea behind Selenoid is to start short-lived container for each Selenium session (i.e. request for browser) and stop it immediately when session is closed. Such approach automatically resolves all issues related to session caches and sharing browser settings among sessions. Every container consists of specific browser version, a corresponding webdriver binary supporting this version and all required dependencies like fonts, graphics toolkits and so on. More than that containers provide an enough level of isolation between browser processes. This allows you to use an unlimited number of different browser versions in parallel and forget about focus issues. Running standard Selenium in containers can also resolve most of the issues above. But to get the same result as Selenoid gives you out of the box you need to use complicated admin-style configuration tools like Ansible or Salt in addition to installing Docker platform.
Important Aspects of Selenium WebDriver
Overcomes Shortcomings of Selenium RCSelenium WebDriver is developed as the successor to Selenium Remote Control (RC). While using Selenium RC, testers have to load web pages by injecting JavaScript functions into a web browser. But Selenium WebDriver takes advantage of the built-in support provided by web browsers to load web pages and drive web browsers. Hence, it becomes easier for web application testers to test a web application across multiple web browsers using a single tool.
Supports Multiple Browsers and Programming Languages
Unlike Selenium IDE, Selenium WebDriver supports several widely used web browsers including Chrome, Firefox and Internet Explorer. The feature makes it easier for testers to execute the same tests against varying web browsers. At the same time, the test automation tool also supports a number of programming languages including Java, PHP, Perl, Ruby, Python, and .NET. It even allows testers to use conditional operations like if-else-then and perform looping while writing test scripts.
Simple Architecture
In addition to overcoming shortcomings of Selenium RC, Selenium WebDriver also features a simple architecture. It controls the web browser from the level of operating system. Hence, the testers can execute test scripts directly without starting the web server. However, the web application testing professionals have to use Selenium commands through the IDE of the specific programming language. They can easily test a web application by combining a web browser and programming language IDE.
Facilitates Real-Time Interaction
While testing a web application, Selenium WebDriver interacts with various page elements in a realistic way. A Selenium testing professional has option to restrict the test automation tool from performing a specific action just like a real user. For instance, developers often prevent users from submitting input by disabling specific text boxes. If a specific test box is disabled for users, Selenium WebDriver will not enter any value through it at the time of testing.
Emulates Real User Actions
In addition to facilitating real-time interaction with the browser, Selenium WebDriver has the capability to emulate certain user actions. It enables users to simulate mouse movements while testing websites. Likewise, the testing professionals can also use specific classes to simulate key press events on keyboard. At the same time, the web application testing tool enables testers to simulate user actions like click and navigation through listeners. The testers can implement WebDriverEventListener methods to perform specific user actions while evaluating the web application.
Accelerates Test Script Execution
Unlike Selenium RC, Selenium WebDriver does not require testers to start the server before executing test scripts. It interacts with the web browsers directly without relying on any intermediary. Also, it controls the web browser through its own engine. The absence of intermediaries makes Selenium IDE much faster than its predecessor. Also, WebDriver accelerates test script execution by giving commands to the web browser directly.
Application Programming Interface (API)
The web application testers even have option to use Selenium WebDriver API as a built-in component of Selenium 2.0. In addition to overcoming the limitations of Selenium-RC API, the WebDriver API also comes with better supports dynamic web pages. The testers can use the API to evaluate the changing page elements without reloading the web page fully. At the same time, they can accelerate dynamic website testing by availing the features provided by the API including file upload or download, pop-ups and dialogs barrier.
Limitation
Being web-application developer or QA automation engineer you can face the following inconveniences in your experience with Selenium server:- You need to install different browsers to your operating system. In real world you are using e.g. Chrome but have to install Firefox and Opera just for Selenium.
- It is complicated to install and use multiple versions of the same browser. Binary packages normally allow only one active browser version. Selenium or its web drivers normally search browser binaries in some predefined paths. So trust me — it is difficult.
- If you are using Selenium to launch a browser from your operating system — it clutters your disk with cache and other temporary files.
- More than that you can’t guarantee that browser settings remain in the same state like it was after fresh installation. For example you can accidentally change proxy server or security settings. This can lead to broken tests.
- Difficult to run several tests in parallel in multiple browsers. Trying to do this causes different issues with window focus: not firing events, unexpected CSS styles and so on.
- Need to know browser versions compatible to installed Selenium version. The same problem occurs with webdriver binaries.
This list of disadvantages is far from being complete. But let’s stop at this point and follow a better way to deal with Selenium testing on your development machine.
Introducing Selenoid
Why starting browsers in containers is so useful? And what is the difference between using standard Selenium in Docker containers and using Selenoid?
The main idea behind Selenoid is to start short-lived container for each Selenium session (i.e. request for browser) and stop it immediately when session is closed. Such approach automatically resolves all issues related to session caches and sharing browser settings among sessions. Every container consists of specific browser version, a corresponding webdriver binary supporting this version and all required dependencies like fonts, graphics toolkits and so on. More than that containers provide an enough level of isolation between browser processes. This allows you to use an unlimited number of different browser versions in parallel and forget about focus issues. Running standard Selenium in containers can also resolve most of the issues above. But to get the same result as Selenoid gives you out of the box you need to use complicated admin-style configuration tools like Ansible or Salt in addition to installing Docker platform.
Installation
Having said that let me show how easy and user-friendly Selenoid is. To start using it you need to complete 3 short steps:- Install Docker. This is usually done with your operating system package manager like APT, Yum or Homebrew. Please refer to Docker documentation on how to do this.
- Create Selenoid configuration directory and generate configuration file:
# mkdir -p /etc/selenoid
# docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aerokube/cm:1.0.0 selenoid --last-versions 2 --tmpfs 128 --pull \
> /etc/selenoid/browsers.json
- The last command will pull Docker images for 2 latest versions of Firefox, Chrome and Opera and generate valid Selenoid config.
- Start Selenoid:
# docker run -d --name selenoid -p 4444:4444 \
-v /etc/selenoid:/etc/selenoid:ro \
-v /var/run/docker.sock:/var/run/docker.sock \
aerokube/selenoid:1.1.1
- That’s it — done in 60 seconds. No need to install Java and download Selenium jar manually. You can now access Selenoid using in your tests the same URL you were using for standard Selenium:
http://localhost:4444/wd/hub
