Parallel Test Execution

Introduction

Right now, when we run all of our tests in our framework, they are run sequentially (e.g. one at a time).  This is arguably ok for now as we only have a total of 5 test scenarios (4 base scenarios and 1 proper test).

But let’s imagine we have loads of tests in our framework, and those tests need testing across multiple browsers.  If we ran all these tests sequentially, the time it would take to complete would be relatively long.

This is where parallel test execution comes in. By using multiple threads, we can run our tests concurrently (at the same time) to reduce the total amount of time it takes to execute all the tests in the framework.

In today’s modern age, most computers have multiple processors, which we can use to our advantage to run tests on a few different forks or threads at the same time.  If we want to run on loads of forks or threads without making the computer unusable, we can scale up using something like Selenium Grid, and then scale up even further with a cloud based service like SauceLabs. We will cover both of these in later parts of this blog series.

Let’s get started 😀

Running our tests concurrently

Our current setup

As we have two feature files (and will have more when the test framework grows), we will run our feature files concurrently against one browser (that we can specify in a config.properties file). In a future blog part where I discuss Jenkins, we can schedule different builds to run our tests in parallel against different specified browsers (by changing the property value for each job).

Editing the build.gradle

To run our feature files in parallel, we first need to create TestRunner classes for each of our feature files. This is not very DRY (Do not Repeat Yourself) and would be time-consuming to do manually if we had loads of features. Luckily, this is where the courgette-jvm plugin comes into play. We can use this plugin to automatically run parallel test execution on either the Features level or Scenarios level, specifying the number of concurrent threads we would like to use in a TestRunner class that uses @CourgetteOptions.

build.gradle dependencies

Adding ‘courgette-jvm’
  1. In IntelliJ, open up the build.gradle file and edit the ‘dependencies’ section to match below…

    Notice that we have removed our previous Cucumber and TestNG related dependencies when we added Courgette, due to the fact that Courgette includes these dependencies in its dependency chain. It is important they are removed otherwise you will run into errors due to version mismatches.

    You will also need to add ‘jcenter()’ as a repository so it can find the Courgette-JVM dependency…

build.gradle tasks

  1. Add the following two tasks in your build.gradle file. The second task will allow us to type in  gradle runTests to run our tests by finding the TestRunner and following the @CourgetteOptions we will specify…

    The whole build.gradle file should look similar to below…

Editing the TestRunner

Because we will now be using Courgette-JVM instead of the normal Cucumber-JVM, we need to update our TestRunner so that it uses @CourgetteOptions with @CucumberOptions inside as one of the @CourgetteOptions.

  • Open up the ‘TestRunner’ class and edit it so that it matches below…

Notice some of the @CourgetteOption that we have set…

  • threads – the number of concurrent threads we will be using
  • runLevel – whether we want to run our tests in parallel at the Feature level or the Scenario level
  • rerunFailedScenarios – A boolean flag for whether we want to rerun any scenarios that fail or not
  • showTestOutput – Whether we want to show the test output
  • reportTargetDir – The target directory where our Courgette generated reports will exist

The rest of the @CucumberOptions should already be familiar to us.

Making our WebDrivers thread-safe

Finally, when running Selenium tests in parallel, your Webdriver object should be thread-safe i.e. a single object can be used with multiple threads at the same time without causing problems. Let’s make both our WebDriver’s thread-safe now by putting them into ThreadLocal<>

ChromeWebDriver

  1. Open up the ‘ChromeWebDriver’ class and edit it to match below…

FirefoxWebDriver

  1. Open up the ‘FirefoxWebDriver’ class and edit it in the same way, like below…

Selecting our browser to run on via a properties file

Instead of using Cucumber tags to specify which browser to run our Features/Scenarios on, when running the full test suite we should specify the browser via a parameter we pass in. This allows us to change it more easily if we add our framework to build servers. We can do this via a simple config.properties file!

Adding a ‘config.properties’ file

  1. In IntelliJ, right-click on the ‘resource’ directory and select ‘New’ -> ‘File’
    • Name the file ‘config.properties’ and click OK
  2. Open up the ‘config.properties’ file and add the following…
    browserName=firefox (note that you could change ‘firefox’ to ‘chrome’ instead)

Adding a new Cucumber hook for @Web

We will now add a @Web cucumber hook, which will use simple if statements to read the value of our ‘browserName’ property and launch the correct browser based on that 🙂

  1. Open up the ‘CucumberHooks’ class in the ‘utils.hooks’ package and add the following ‘@Before(“@Web”)’ hook, like below…

Running our Tests

  1. Add a ‘@Web’ tag at the top of both our feature files (example below)…
  2. Open up a Terminal (or Command prompt window)
  3. Change directory (cd) in to the project root
  4. Run the tests via the command  gradle runTests and rejoice! 😀
Liked it? Take a second to support Thomas on Patreon!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.