3

I write some automation using selenium and java.

I use build.gradle to run cucumber features.

Each feature has some tests.

Is there a ready made way to make the independent scripts run in parallel?

They all use selenuim ChromeWebDriver.

If there is none, how would you advise me to write such?

Opal
  • 81,889
  • 28
  • 189
  • 210
Elad Benda2
  • 13,852
  • 29
  • 82
  • 157
  • 1
    I don't think this question is a duplicate. This question is specifically asking about how to execute cucumber tests in parallel using Gradle – rcgeorge23 Jan 05 '21 at 08:23

2 Answers2

4

here is one approach that worked for me fine ( important note: using maven as build manager )

===========================================

You will need to have Maven and Firefox installed on your machine in order to run this example.

Once you have retrieved the source, you can run by navigating into the Cucumber-JVM-Parallel directory and issuing the command:

mvn clean install

This will run the example project and start two browser windows concurrently. Each browser window corresponds to a Cucumber feature file in the example. Once the run is complete, a report will have been generated at /target/cucumber-report/index.html.

The rest of this post will go into further detail on the structure of the example project, though it is assumed that you have some prior experience of Cucumber. If not, the Cucumber-JVM readme is a great place to start.

Feature files

The first thing you need is your feature files to describe the behaviour you expect. In this example, we have two separate features, though you can also run scenarios within a single feature in parallel.

The way we can do is is by using Cucumber tags, which can be applied either to all scenarios in a feature or to individual scenarios.

Cucumber tags

Above, you can see that we have two feature files. These reside in the ‘src/test/resources’ folder. Each feature file is tagged (@autocorrect and @search), and contains a single scenario.

Glue code

Now that we have our scenarios, we need to add some glue code to tie each step into our underlying test framework

These are referred to as step definitions, and can be found in ‘src/java/cucumber.jvm.parallel/cucumber/stepdefs’.

code snippet

In the above snippet, you can see that we use an instance of ShareDriver to communicate directly with a browser window. This is based on one of the cucumber examples for sharing a single browser session between all tests (using dependency injection) to remove the need for starting up a browser instance per test and thus speed up execution. In our case, this results in one browser session per thread. The ShareDriver class can be found in ‘/src/test/java/cucumber.jvm.parallel/cucumber’.

Page Objects

The snippet also shows that we use an instance of ‘SearchPageObject’, which is simply a class which represents the Google search page, found in ‘/src/test/java/cucumber.jvm.parallel/pageobjects’.

This is not required, but it’s good practice to use the page object pattern for ease of maintainability on a larger project.

page object

Above, you can see that the page object contains identifiers for elements on the page as well as methods specific to that page.

Runners

The next stage in the process is adding the test runners. We are using JUnit as opposed to the CLI, and this is where we need to start structuring things specifically to handle parallel running of tests.

runners

In the above snippet from ‘SearchAT.class’ you can see that we are specifying the location of the feature files. We are also specifying a tag (@search) which relates to one of our cucumber feature file tags and a html report destination for test results.

What this says is “run all tests tagged as @search and write results to /search folder”.

We then have another class, ‘AutoCorrectAT’ which does the same for all tests tagged ‘@autocorrect’. Both of these classes can be found under ‘/src/test/java/cucumber.jvm.parallel/cucumber’.

Adding another thread is simply a case of adding a new runner class with a different tag.

Parallel Test Runs

Up to this point, the instructions are identical to creating a relatively simple non-parallel set of Cucumber-JVM tests using WebDriver to interact with a website.

We now need to go to the Maven POM file to see how we are making the tests run in parallel.

POM config

In the above snippet, you can see that the maven-surefire-plugin is used to run our acceptance tests – any classes that end in *AT will be run as a JUnit test class. Thanks to JUnit, making the tests run in parallel is now a simple case of setting the forkCount configuration option. In the example project, this is set to 5, meaning that we can run up to 5 threads (ie, 5 runner classes) at a time.

============================

More details you can get in Running Cucumber-JVM tests in parallel article

Hope this helps you.

eugene.polschikov
  • 7,254
  • 2
  • 31
  • 44
  • what is the difference if i'm using gradle build manager ? – Elad Benda2 Jul 23 '14 at 13:06
  • frankly speaking , worked only with maven, therefore for me it's a bit difficult to compare maven and gradle. Take a look: http://stackoverflow.com/questions/18072456/difference-between-gradle-and-maven . Whatever, I thing they both have close semantics – eugene.polschikov Jul 24 '14 at 10:33
3

I assume that you use a test task to execute your Cucumber Runners? If so, you can use this in your build.gradle:

tasks.withType(Test) {
    maxParallelForks = 5
}

task uiTests(type: Test){  includes = ['**/*Cucumber*'] }

This uiTests Task assumes that all Runner Classes have Cucumber in their name, if this doesnt suit you, you can just write every Runner class in there.

Now if you provide an own runner for each feature file, the different runners will be executed in parallel

You can give each Feature a different tag at the top, and then let each runner only execute one tag. This can be configured like

@CucumberOptions{tags = @Feature1}

In each runner class

Dude
  • 692
  • 1
  • 4
  • 25
  • That's the same approach I came up with after looking at different alternatives that were for Maven, required handcrafted and customized code, or required third-party code that wasn't mature enough. Although I didn't think about using tags. I know it's late, but hope that people looking for this, find your post useful. – Roberto S. Jan 21 '16 at 23:01