Parallel and CI runs

A parallel run executes several tests at the same time, each in its own browser. A suite that takes two hours runs once a night; the same suite in fifteen minutes can run on every pull request (a proposed code change that teammates review before it is merged, that is, added to the main code). CI (continuous integration) is the server, such as Jenkins or GitHub Actions, that runs those tests on every change. Parallel runs and CI test a framework's design harder than anything else, so interview questions focus on doing them safely.

TestNG parallel settings

<suite name="Regression" parallel="methods" thread-count="4">

A thread is one line of work inside the Java process; four threads can run four tests at once. The parallel attribute decides what gets its own thread:

• methods: each test method can run in its own thread. This is the most parallel mode and needs the strictest isolation (tests must share nothing).
• classes: each class runs in its own thread, and the methods inside a class run in order.
• tests: each <test> block runs in its own thread. A common use is one block per browser.
• instances: instances of the same class run in separate threads.

The default is no parallelism, and thread-count defaults to 5. DataProvider rows run in parallel with @DataProvider(parallel = true), using a separate pool (a group of ready threads) whose size, data-provider-thread-count, defaults to 10.

One driver per thread

The classic bug is a static WebDriver field in a base class. A static field has one value shared by every thread. With parallel methods, one test's set-up replaces the driver another test is using: clicks land in the wrong browser, sessions close mid-test, and failures look random.

The fix is a ThreadLocal, a holder that keeps a separate value for each thread:

public final class DriverManager {
    private static final ThreadLocal<WebDriver> DRIVER = new ThreadLocal<>();

    public static WebDriver getDriver() { return DRIVER.get(); }

    public static void start(WebDriver driver) { DRIVER.set(driver); }

    public static void stop() {
        WebDriver driver = DRIVER.get();
        if (driver != null) {
            driver.quit();
            DRIVER.remove();
        }
    }
}

public abstract class BaseTest {
    @BeforeMethod
    public void openBrowser() { DriverManager.start(DriverFactory.create()); }

    @AfterMethod(alwaysRun = true)
    public void closeBrowser() { DriverManager.stop(); }
}

remove() matters because TestNG reuses threads. Without it, a later test on the same thread could find the old, already quit driver.

Other shared things

• Test data: two tests logging in as the same user can log each other out. Give each test its own data or account.
• Files: screenshot and download names must be unique, for example the test name plus the time.
• Reports and logs: keep one report entry per test, often in a ThreadLocal too, and put the thread name in the log format.
• Static state in helpers, such as counters, caches or a shared SoftAssert, causes the same mix-ups as a static driver.

JUnit 5

JUnit 5 runs tests one at a time until you enable parallel runs, for example in junit-platform.properties:

junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent

The default mode is same_thread, and @Execution(ExecutionMode.CONCURRENT) changes it for one class. The same isolation rules apply.

Capacity, the command line and CI

Each thread needs a browser, and browsers need CPU and memory. Start with as many threads as the machine can run browsers comfortably, measure, then add Selenium Grid (a setup that runs browsers on several machines) when one machine is not enough.

Everything CI needs is one command: mvn clean test -Dbrowser=chrome -Denv=qa -Dgroups=smoke -Dheadless=true. To reproduce one failure locally, mvn test -Dtest=LoginTest#validLogin runs a single method. A typical pipeline (the list of steps the CI server runs) checks out the code (downloads it) and sets up the JDK (the Java tools), starts browsers (headless, meaning with no visible window, on the machine, or a Grid in containers, which are small packaged environments such as Docker), runs the Maven command, and always publishes target/surefire-reports and the HTML report, even when tests fail. A failed smoke run (a short run of the most important tests) blocks the merge. Passwords come from the CI secret store, and the pipeline file (a Jenkinsfile or a workflow file) lives in the repository.

How to answer in an interview

For "how do you run tests in parallel?", give three parts: the setting ("parallel="methods" with a thread count in testng.xml"), the driver ("a ThreadLocal driver manager, quit and removed in an alwaysRun teardown"), and independence ("each test makes its own data, and file names are unique").

Common mistakes

• A static WebDriver in the base class.
• Forgetting remove() on the ThreadLocal.
• More threads than the machine can run browsers for.
• Tests that pass alone but fail together. Look for shared state first.

Recap

TestNG's parallel and thread-count settings run tests at once. Each thread needs its own driver, kept in a ThreadLocal and removed after the test. Tests must not share data, files or static state. CI runs the same Maven command with -D options and always publishes the results.