Test parallelization in CI in Selenium Java - Build an Automation Script

Verify login functionality runs correctly in parallel tests on CI

Preconditions (3)

Step 1: Open the login page URL in a browser

Step 2: Enter '[e-mail]' in the email field

Step 3: Enter 'Password1!' in the password field

Step 4: Click the login button

Step 5: Verify the user is redirected to the dashboard page

Step 6: Repeat the above steps simultaneously with '[e-mail]' and '[e-mail]' credentials in separate test threads

✅ Expected Result: All parallel tests complete successfully with each user redirected to their dashboard without interference or errors

Automation Requirements - TestNG with Selenium WebDriver

Assertions Needed:

Verify current URL contains '/dashboard' after login

Verify login button is clickable before clicking

Verify no test interference occurs between parallel threads

Best Practices:

Use TestNG @DataProvider for parallel data-driven tests

Use explicit waits to handle dynamic page elements

Configure TestNG XML to enable parallel test execution

Use thread-safe WebDriver instances for each test thread

Automated Solution

Selenium Java

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;

import java.time.Duration;

public class ParallelLoginTest {

    private ThreadLocal<WebDriver> driver = new ThreadLocal<>();

    @BeforeMethod
    public void setUp() {
        // Setup ChromeDriver for each thread
        System.setProperty("webdriver.chrome.driver", "path/to/chromedriver");
        driver.set(new ChromeDriver());
    }

    @Test(dataProvider = "loginData", threadPoolSize = 3)
    public void testLogin(String email, String password) {
        WebDriver webDriver = driver.get();
        webDriver.get("https://example.com/login");

        WebDriverWait wait = new WebDriverWait(webDriver, Duration.ofSeconds(10));

        WebElement emailField = wait.until(ExpectedConditions.elementToBeClickable(By.id("email")));
        emailField.clear();
        emailField.sendKeys(email);

        WebElement passwordField = webDriver.findElement(By.id("password"));
        passwordField.clear();
        passwordField.sendKeys(password);

        WebElement loginButton = wait.until(ExpectedConditions.elementToBeClickable(By.id("loginBtn")));
        loginButton.click();

        // Wait for dashboard URL
        wait.until(ExpectedConditions.urlContains("/dashboard"));

        String currentUrl = webDriver.getCurrentUrl();
        Assert.assertTrue(currentUrl.contains("/dashboard"), "User should be redirected to dashboard");
    }

    @DataProvider(name = "loginData", parallel = true)
    public Object[][] loginData() {
        return new Object[][] {
            {"[e-mail]", "Password1!"},
            {"[e-mail]", "Password2!"},
            {"[e-mail]", "Password3!"}
        };
    }

    @AfterMethod
    public void tearDown() {
        driver.get().quit();
        driver.remove();
    }
}

This test class uses TestNG and Selenium WebDriver to run login tests in parallel.

We use ThreadLocal<WebDriver> to ensure each test thread has its own browser instance, avoiding interference.

The @DataProvider supplies three sets of login credentials and is marked parallel=true to enable parallel execution.

The @Test method uses explicit waits to ensure elements are ready before interacting, improving reliability.

Assertions check that after login, the URL contains '/dashboard', confirming successful login.

Finally, @BeforeMethod and @AfterMethod setup and clean up the WebDriver instances per test thread.

This setup is suitable for running in a CI environment configured to run TestNG tests in parallel.

Common Mistakes - 4 Pitfalls

Using a single WebDriver instance shared across parallel tests

Not using explicit waits before interacting with elements

Hardcoding test data inside test methods instead of using DataProvider

{'mistake': 'Not configuring TestNG XML for parallel execution', 'why_bad': 'Tests will run sequentially, missing the benefit of parallelization in CI.', 'correct_approach': "Configure TestNG suite XML with parallel='methods' or parallel='tests' and thread-count."}

Bonus Challenge

Now add data-driven testing with 3 different user credentials to run in parallel

Show Hint

Practice

1. What is the main benefit of running tests in parallel in a CI environment?

easy

A. It increases the number of test cases by duplicating them.

B. It ensures tests run in a specific order to avoid failures.

C. It reduces the total test execution time by running tests simultaneously.

D. It disables tests that are flaky to improve stability.

Solution

1. Step 1: Understand parallel test execution

   Parallel execution means running multiple tests at the same time instead of one after another.

2. Step 2: Identify the benefit in CI

   Running tests simultaneously saves time, making the feedback faster in continuous integration.

3. Final Answer:

   It reduces the total test execution time by running tests simultaneously. -> Option C

4. Quick Check:

   Parallel tests = faster execution [OK]

Hint: Parallel tests run together to save time [OK]

Common Mistakes:

• Thinking parallel means tests run in order
• Believing parallel increases test count
• Assuming parallel disables flaky tests

2. Which TestNG XML attribute correctly enables parallel test execution?

easy

A.

B.

C.

D.

Solution

1. Step 1: Recall TestNG XML syntax for parallelism

   The correct attribute to enable parallel execution is 'parallel' with values like 'methods', 'tests', or 'classes'.

2. Step 2: Identify correct thread count attribute

   The attribute 'thread-count' sets how many threads run in parallel.

3. Final Answer:

   <suite parallel="methods" thread-count="4"> -> Option B

4. Quick Check:

   parallel + thread-count = correct syntax [OK]

Hint: Use parallel and thread-count attributes in TestNG XML [OK]

Common Mistakes:

• Using non-existent attributes like runParallel
• Confusing thread-count with threads
• Using order="sequential" disables parallelism

3. Given this TestNG XML snippet, what is the maximum number of tests running at the same time?

<suite name="Suite" parallel="tests" thread-count="3">
  <test name="Test1">...</test>
  <test name="Test2">...</test>
  <test name="Test3">...</test>
  <test name="Test4">...</test>
</suite>

medium

A. 3 tests run simultaneously

B. 4 tests run simultaneously

C. 1 test runs at a time

D. 2 tests run simultaneously

Solution

1. Step 1: Understand parallel="tests" meaning

   Setting parallel="tests" means TestNG runs multiple <test> tags at the same time.

2. Step 2: Check thread-count value

   thread-count="3" limits the number of simultaneous threads to 3, so max 3 tests run together.

3. Final Answer:

   3 tests run simultaneously -> Option A

4. Quick Check:

   parallel=tests + thread-count=3 means 3 parallel tests [OK]

Hint: thread-count limits max parallel tests [OK]

Common Mistakes:

• Assuming all tests run at once ignoring thread-count
• Confusing parallel="methods" with parallel="tests"
• Thinking thread-count is ignored

4. You configured TestNG with parallel="methods" and thread-count="2". Your tests share a static WebDriver instance. What problem will most likely occur?

medium

A. Tests will fail due to WebDriver conflicts from shared instance.

B. Tests will run faster without any issues.

C. Tests will run sequentially ignoring parallel settings.

D. Tests will create multiple WebDriver instances automatically.

Solution

1. Step 1: Understand parallel methods with shared static WebDriver

   Parallel methods run at the same time, but sharing a static WebDriver means all tests use the same browser instance.

2. Step 2: Identify concurrency issues

   Sharing one WebDriver causes conflicts like commands overlapping, leading to test failures.

3. Final Answer:

   Tests will fail due to WebDriver conflicts from shared instance. -> Option A

4. Quick Check:

   Shared static WebDriver + parallel = conflicts [OK]

Hint: Avoid shared static WebDriver in parallel tests [OK]

Common Mistakes:

• Assuming shared WebDriver works fine in parallel
• Thinking parallel disables shared resource conflicts
• Believing TestNG creates separate WebDriver automatically

5. You want to run your Selenium tests in parallel in CI using TestNG. Your suite has 5 test classes, each with 3 test methods. You want to run all methods in parallel but limit total threads to 6. Which TestNG XML configuration is correct?

hard

A.

B.

C.

D.

Solution

1. Step 1: Identify parallel="methods" for running all test methods in parallel

   To run all methods in parallel, use parallel="methods" in the suite tag.

2. Step 2: Set thread-count="6" to limit total threads

   thread-count="6" limits the number of simultaneous threads to 6, matching the requirement.

3. Step 3: Confirm classes are inside a single <test> tag

   All classes are grouped under one <test> tag, so methods from all classes run in parallel within the thread limit.

4. Final Answer:

   <suite parallel="methods" thread-count="6"> -> Option D

5. Quick Check:

   parallel="methods" + thread-count="6" + single <test> [OK]

Hint: Use parallel="methods" with thread-count to control concurrency [OK]

Common Mistakes:

• Using parallel="classes" runs classes in parallel, not methods
• Using thread-count too high ignores limit
• Splitting classes into multiple tests changes parallel behavior