Speed Up Selenium Tests with JUnit 5 Parallel Execution and Advanced Features

Parallel Test Execution with JUnit 5

JUnit 5 provides built‑in support for running tests in parallel. The following Gradle command runs all methods of TodoMvcTests concurrently:

./gradlew clean test --tests *TodoMvcTests -Djunit.jupiter.execution.parallel.enabled=true -Djunit.jupiter.execution.parallel.mode.default=concurrent

When executed, two Chrome instances are launched simultaneously and the total test time drops to a fraction of the original duration.

Controlling Test Execution Order

Although tests should be independent, some scenarios require a specific order. JUnit 5 allows ordering via the @Order annotation together with @TestMethodOrder(MethodOrderer.OrderAnnotation.class):

@ExtendWith(SeleniumExtension.class)
@SingleSession
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
@DisplayName("Managing Todos")
class TodoMvcTests {
    @Test
    @Order(1)
    @DisplayName("test001")
    void createsTodo() {}

    @Test
    @Order(2)
    @DisplayName("test002")
    void createsTodosWithSameName() {}
}

Single‑Browser Session with Selenium Jupiter

By default each test creates a new Chrome instance, which is time‑consuming. Adding the @SingleSession annotation at the class level initializes the browser once before all tests and closes it after the suite finishes.

Implementation requires injecting the driver via the constructor instead of using @BeforeEach:

private final ChromeDriver driver;

public TodoMvcTests(ChromeDriver driver) {
    this.driver = driver;
    this.todoMvc = PageFactory.initElements(driver, TodoMvcPage.class);
    this.todoMvc.navigateTo();
}

@AfterEach
void storageCleanup() {
    driver.getLocalStorage().clear();
}

Running the suite now completes in roughly half the time.

Parallel Execution with a Shared Browser Instance

When parallel execution is enabled, each test method normally receives its own driver. Combining @SingleSession with parallel class execution (but same‑thread method execution) shares a single browser across methods:

./gradlew clean test --tests *TodoMvcTests \
    -Djunit.jupiter.execution.parallel.enabled=true \
    -Djunit.jupiter.execution.parallel.mode.default=same_thread \
    -Djunit.jupiter.execution.parallel.mode.classes.default=concurrent

Configuring Selenium Jupiter Driver Settings

To inject a WebDriver instead of a concrete ChromeDriver and to control the browser type at runtime, modify the test class constructor and use Java system properties. Example Gradle configuration:

test {
    systemProperties System.getProperties()
    useJUnitPlatform()
    testLogging {
        events "passed", "skipped", "failed"
    }
}

Run tests with a specific browser:

./gradlew clean test --tests *TodoMvcTests -Dsel.jup.default.browser=firefox

Additional properties can enable screenshot capture at the end of the suite and define output format and folder.

Parameterized Tests in JUnit 5

Parameterized tests run the same method with different data sets. JUnit 5 supports several sources, such as @ValueSource, @MethodSource, @CsvSource, and @CsvFileSource. Example using a CSV file located in src/test/resources:

@ParameterizedTest
@CsvFileSource(resources = "/todos.csv", numLinesToSkip = 1, delimiter = ';')
@DisplayName("Creates Todo with given name")
void createsTodo(String todo) {
    todoMvc.createTodo(todo);
    assertSingleTodoShown(todo);
}

CSV content:

todo;done
Buy the milk;false
Clean up the room;true
Read the book;false

A more complex example consumes both columns and performs additional actions based on the done flag.

Enhanced Assertions with AssertJ

JUnit’s built‑in assertions are limited; AssertJ offers a fluent API, soft assertions, and rich type support. Add the dependency to build.gradle:

testCompile('org.assertj:assertj-core:3.13.2')

Static import org.assertj.core.api.Assertions.* and use assertThat for expressive checks, e.g.:

assertThat(todoMvc.getTodosLeft()).isEqualTo(3);
assertThat(todoMvc.getTodos())
    .hasSize(3)
    .containsSequence(buyTheMilk, cleanupTheRoom, readTheBook);

These assertions produce clearer error messages and improve test readability.