Run Parallel Tests With Selenium

---

Running tests sequentially multiplies wait time across every test. Parallel execution on the TestMu AI cloud grid lets you run hundreds of tests simultaneously across different browser and OS combinations, cutting build times from hours to minutes.

How Parallel Testing Works

---

Each parallel test opens its own session on the grid. Your framework splits the test suite into threads or processes, and each one connects to a separate browser instance on TestMu AI.

Your Machine
  ├── Thread 1 → Chrome / Windows 11
  ├── Thread 2 → Firefox / Windows 10
  ├── Thread 3 → Safari / macOS Sonoma
  └── Thread 4 → Edge / Windows 11

The number of sessions you can run simultaneously depends on your TestMu AI plan's concurrency limit.

Run Parallel Tests by Framework

---

Each framework handles parallelism differently. Below are the commands and configurations for the most common frameworks.

TestNG

TestNG uses parallel="tests" and thread-count in the testng.xml file to run tests in parallel.

parallel.testng.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite thread-count="3" name="ParallelSuite" parallel="tests">

  <test name="Chrome Test">
    <parameter name="browser" value="Chrome"/>
    <parameter name="browserVersion" value="latest"/>
    <parameter name="platformName" value="Windows 11"/>
    <classes>
      <class name="com.example.SampleTest"/>
    </classes>
  </test>

  <test name="Firefox Test">
    <parameter name="browser" value="Firefox"/>
    <parameter name="browserVersion" value="latest"/>
    <parameter name="platformName" value="Windows 10"/>
    <classes>
      <class name="com.example.SampleTest"/>
    </classes>
  </test>

  <test name="Safari Test">
    <parameter name="browser" value="Safari"/>
    <parameter name="browserVersion" value="latest"/>
    <parameter name="platformName" value="macOS Sonoma"/>
    <classes>
      <class name="com.example.SampleTest"/>
    </classes>
  </test>

</suite>

Run with Maven:

mvn test -D suite=parallel.xml

JUnit

JUnit uses a custom Parallelized runner or JUnit 5's junit.jupiter.execution.parallel.enabled property.

JUnit 5 - add to junit-platform.properties:

junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent
junit.jupiter.execution.parallel.config.strategy=fixed
junit.jupiter.execution.parallel.config.fixed.parallelism=3

JUnit 4 - run with Maven parallel profile:

mvn test -P parallel

PyTest

Use the pytest-xdist plugin to run tests in parallel.

Install it:

pip install pytest-xdist

Run with a specified number of workers:

pytest -n 3

Each worker opens its own browser session on the TestMu AI grid.

Mocha

Use the --parallel flag (Mocha 8+) to run test files in parallel:

mocha --parallel --jobs 3

Or use a test runner like mocha-parallel-tests:

npm install mocha-parallel-tests
mocha-parallel-tests --max-parallel 3

NUnit

NUnit runs tests in parallel using the [Parallelizable] attribute:

[TestFixture]
[Parallelizable(ParallelScope.All)]
public class ParallelTests
{
    // Each test method runs in its own thread
}

Run from the command line:

dotnet test

NUnit handles thread management automatically.

RSpec

Use the parallel_tests gem:

gem install parallel_tests

Run with a specified number of processes:

parallel_rspec -n 3 spec/

PHPUnit

Use the paratest package for parallel PHPUnit execution:

composer require brianium/paratest

Run with a specified number of processes:

vendor/bin/paratest -p 3

xUnit

xUnit runs tests in parallel by default across test collections. Run with:

dotnet test --filter "profile=parallel"

Best Practices

---

Follow these guidelines to get the most out of parallel execution.

• Match thread count to your concurrency limit. Running more threads than your plan allows queues the excess sessions. Check your concurrency limit in the TestMu AI Dashboard.
• Keep tests independent. Parallel tests must not share state, test data, or depend on execution order. Each test should set up and tear down its own data.
• Always call driver.quit(). If a test exits without quitting, the session stays open until the idle timeout expires, wasting concurrency slots.
• Use unique build and test names. Set the build and name capabilities to identify which parallel thread ran which test on the dashboard.
• Start small. Begin with 2-3 parallel threads and increase gradually. Monitor the TestMu AI Automation Dashboard for failures caused by test interference.

Verify Your Parallel Runs

---

Check the dashboard to confirm tests ran simultaneously.

Visit the TestMu AI Automation Dashboard and open your build. If tests ran in parallel, you will see multiple sessions with overlapping start times. The build duration should be roughly equal to the duration of the longest individual test, not the sum of all tests.