WebDriverManager fabric example for Selenium based frameworks

I guess most of the people who are involved in the automated testing of web applications to some extent, they came up to the managing of browsers and their drivers while working with Selenium-based test frameworks. There might be a lot of solutions how to make their life easier. Some out-of-the-box frameworks (like Selenide) have already implemented WebDriver managers internally, however, in some cases, we need to handle it by ourselves.

The most known and possible solution for such cases is creating a custom WebDriver manager based on the Factory design pattern. There are lots of different implementations on GitHub and you can easily google them but today I’d want to share one of the latest experiments that I made (inspired by this solution with enums). So, here we go…

Challenge: to implement a Browser Manager (i.e. WebDriver manager) which simplifies running tests on different browsers, including parallel execution.

First of all, let’s get rid of annoying drivers binaries management! As you know, each browser has its own driver binary which should be downloaded and its location should be added to the classpath. The WebDriverManager project provides the API for downloading necessary drivers and configuring system properties automatically. All you need is love to add its dependency (through Maven or Gradle) and call a fabric method relevant to a needed browser:

It’s pretty easy, isn’t it? It supports Firefox, Chrome, Opera, IE, Edge and PhantomJS browsers for now but I’m going to add the HtmlUnit browser in the final solution also. The WebDriverManager mentioned above allows us to specify also architecture, driver version and several other parameters if necessary).

Following the code above and using the example for enums, let’s create our own Browser enum with all browsers listed before:

The logic of the whole enum is incredibly simple: there is the abstract initialize() method which must be implemented for each member of the enum. Each overridden initialize() method (excepts for the HtmlUnit driver) sets up an instance of a required driver manager class and then returns a required driver after all dependencies are downloaded and configured. In order to make the WebDriverManager API more thread-safe while running tests in different browsers in parallel, I also put all code related to the BrowserManager.class inside the synchronized {..} block.

The final step before moving forward to the fabric usage in the framework is to create the fabric. Let’s make the new BrowserProvider class :

There are 2 methods for the RemoteWebDriver creation and 2 similar ones for the local test tun. All of them take a Browser as a parameter which can be passed from a test (or any other setup class that you may use). Optionally, methods can take DesiredCapabilities.

Now we can use the fabric from the test code:

As you have noticed, I used TestNG annotations inside the test code. It’s because I prefer this test framework from the easy parametrization point of view, so it’s suitable for demonstrating a parallel test execution in different browsers. Here is how the typical TestNG file may look like:

When you run your test through the above-mentioned TestNG file, you’ll see Firefox and Edge browsers starting and running tests in parallel. You can easily add any other of supported browsers and run them in parallel as well as separately. Please note that the very first run for each browser might take more time – WebDriverManager will download necessary binaries to the local Maven repository.

The complete project code is available on GitHub, so feel free to add it to your progect, use and / or modify according to your needs, if necessary. Any suggestions are welcome!

Like this post?

Subscribe to updates from my blog, if you don't want to miss more interesting future posts and materials

Please check your email and confirm subscription

Pin It on Pinterest

Share This