Skip to main content

Selenium Grid

Selenium WebDriver is a great and powerful tool when it comes to web test automation. The pros would be appreciated by everybody who test web based applications. However, along with the enlargement of our test base, there are some limitations, and use of single WebDriver implementation on the local machine becomes insufficient. The answer to this problem can be Selenium Grid tool, which distribute tests execution to remote machines.


What is Selenium Grid and why use it? 

Selenium Grid allows you to perform tests execution on different machines, with multiple browsers and operating systems at the same time, regardless of the local development environment. It creates a central hub, which distributes the execution to remote nodes. 

Grid architecture consists of one hub and one or more nodes. Hub is placed on the single machine (local or remote). It is the central point which distributes tests to nodes, depending on configuration and accessibility. Nodes are machines on which the tests are performed. Nodes may differ from each other with operating systems and browsers. 

In this tutorial we will install and set up basic grid configuration on the local machine, consisting of a hub and two nodes. Then we will write simple WebDriver test and execute it on our grid.

Installation 

First of all – make sure you have java jdk installed. Second – install Selenium Grid 2.0. To do it, simply download Selenium Server jar from seleniumHq website: http://docs.seleniumhq.org/download/ (look under the section “Selenium-Server (formerly Selenium-RC).” When the installation is complete, unzip the downloaded archive and you’re done!

Setting Up 

We’ll start with the hub configuration. To start selenium grid hub on the local machine, open the terminal, go to the directory where you’ve downloaded selenium-server and run the command (for version 2.45.0):

java -jar selenium-server-standalone-2.45.0.jar -role hub

you should see information about booting services under the default 4444 port:


Open any browser and go to http://localhost:4444/grid/console . You should see empty console of our grid:

The next step is to set up nodes. By default, a single node will have an operating system same as host machine, and will have five Firefox and Chrome instances and one Internet Explorer. To register a node on localhost at port 5555 open a new terminal and run the command:

java -jar selenium-server-standalone-2.45.0.jar -role node -hub http://localhost:4444/grid/register

Node will be created under default 5555 port:


Refresh grid console and you should see our first node:

Of course nothing prevents us from registering node located on a remote machine. Instead of pointing to localhost, just give a host name of another machine. We can also override the default configuration node parameters. To do this, we will register a second node, but this time with changing default configuration. We want our node to run on Linux, and to have only Firefox in version 30.0. We also need to override the default port, because port 5555 we have already taken for the first node. Open a new terminal and execute:

java -jar selenium-server-standalone-2.45.0.jar -role node -hub http://localhost:4444/grid/register -browser browserName=firefox,version=30.0,maxInstances=5,platform=LINUX -port 6666

Second node should register under 6666 port:


Refresh console tab again and there should be our second node with custom configuration:


Writing tests 

The only thing we need to change to run selenium tests on the grid is the WebDriver initialization. We must indicate on which browser and system you want them to be executed. To determine the browser, initialize DesiredCapabilities object with firefox method:

DesiredCapabilities capability = DesiredCapabilities.firefox();

Next thing is the RemoteWebDriver initiation with our hub address and capability object:

WebDriver driver = new RemoteWebDriver(new URL(“http://localhost:5555/wd/hub”), capability);

Above configuration will execute tests on the hub. The hub will send them to nodes which meets specified requirements (in our case it is firefox browser). Nothing stands in the way to determine our execution requirements more accurately. For example, if you declare the requirements as follows:

DesiredCapabilities capability = DesiredCapabilities.firefox();
capability.setPlatform(Platform.LINUX); 
capability.setVersion(“30.0”);

This test will be performed only on the nodes that have Linux and firefox installed and with version 30.0. Whole example code below:

Etykiety:

Popular posts from this blog

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous...
Read more

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >      ...
Read more

REST API mocking with Wiremock

Probably every developer or tester have used mocks at least once in their daily professional work. Functionality mocking is an excellent way to improve development process of integrated systems production, or testing heavy dependent application functionalities. With the growth of popularity of REST webservices, API mocking is becoming hot topic. In this article I would like to introduce a simple getting-started tutorial of setting basic standalone REST API mock server with Wiremock on your local machine. Wiremock is a simple library written in Java for mocking web services. Installation  To run standalone wiremock server, download jar from here and run: $ java -jar wiremock-1.55-standalone.jar you should see: This means that wiremock has started an empty mock server on localhost on port 8080. After you navigate to http://localhost:8080/__admin/ in your browser, you should get empty mappings entity: You can also change default port by adding --port...
Read more