Parallel WebDriver executions using TestNG

In this post, we will see how does one make use of TestNG to kick off parallel UI tests using WebDriver.

So lets try doing this with a typical cooking recipe style :)

So here are the ingredients that are required.

• A Factory class that will create WebDriver instances
• A Manager class that can be accessed to retrieve a WebDriver instance
• A TestNG listener that will be responsible for instantiating the WebDriver instance automatically

So without wasting any time lets see how this all blends in.

First lets look at our Factory class. This is a very simplified Factory class that will create instances of WebDriver based upon the browser flavour. I have purposefully kept it simple only for illustration purposes:
Here’s how the Factory class will look like:

As you can see its a very simple class with a static method that creates WebDriver instances. The one interesting part to be noted here is that the class has been purposefully given only package visibility [ notice how the keyword "public" is missing from the class declaration ]. One of the many aspects that are involved in designing APIs is “Hide what is not necessary to be visible to your user”. For you to be able to drive a car, you don’t need to know how the piston works or how the fuel injection happens do you :)

Now lets take a look at how our Manager class would look like. The Manager class essentially uses a concept in java called ThreadLocalvariables.

The code would look like below :

Were you surprised that its such a small class ? :)
So as you can see we basically have a static ThreadLocal variable wherein we are setting webDriver instances and also querying webdriver instances as well.

Next comes the TestNG listener. The role of the TestNG listener is to perform “Automatic webdriver instantiation” behind the scenes without your test code even realising it. For this we will make use of IInvokedMethodListener so that the WebDriver gets instantiated right before a Test Method gets invoked and the webDriver gets automatically quit right after the Test method.
You can improvize this by incorporating custom annotations as well and parsing for your custom annotations [ The current implementation that you will see basically spawns a browser irrespective of whether you want to use it or not. That‘s not a nice idea all the time is it ]

Now that we have shown all of the ingredients, lets take a look at a sample test as well, which is going to use all of this.

As you can see its a very simple test class with two test methods. Each of the test methods opens up a different website. I have also add print statements for printing the thread id [yes thats the only reliable way of figuring out if your test method is running in parallel or in sequential mode. If you see unique values for Thread.currentThread().getId() then you can rest assured that TestNG is invoking your test methods in parallel.
We are printing the hashCode() values for the browser to demonstrate the fact that there are unique and different webDriver instances being created for every test method. [ Remember hashCode() value for an object would always be unique ]

Now lets take a look at how our suite file looks like :

So when you run this test this is how your output would look like [ apart from you seeing two firefox windows popup on your desktop ]

And thus we have managed to leverage TestNG and run WebDriver tests in parallel without having to worry about race conditions or leaving browsers open etc.,

Hope that clears out some of the confusions and helps you get started with WebDriver automation powered by TestNG.