What Is Browser Automation?

Browser automation means controlling a web browser using code — for testing, scraping, or performing repetitive tasks. Traditionally, tools like Selenium WebDriver, Puppeteer, Cypress, and Playwright have powered this automation revolution. But each came with different architectures, protocols, and quirks. WebDriver BiDi is changing that.

Enter WebDriver BiDi

WebDriver BiDi (short for bidirectional) is a W3C standard-in-progress that enables two-way, real-time communication between your automation scripts and the browser. Unlike the classic WebDriver (which used HTTP in a request-response model), BiDi uses WebSockets, allowing the browser to push events like network requests, console logs, or JavaScript exceptions directly to your code. In short:

• 🦾 More reliable automation
• 🌐 Better browser control
• 📃 One unified standard
• ⚒ Simpler tooling and fewer hacks

Specification: https://www.w3.org/TR/webdriver-bidi/

Why WebDriver BiDi Matters

Traditional W3C WebDriver works like a walkie-talkie: your code sends a command, waits, and gets a response. WebDriver BiDi, on the other hand, is like a live conversation — both sides talk freely. That means we can now:

• Capture console logs in real time.
• Intercept and modify network traffic.
• React instantly to browser events.
• Simulate complex user input with more precision.

BiDi merges two worlds:

• The reliability of the W3C WebDriver protocol.
• The real-time capabilities of the Chrome DevTools Protocol (CDP).

Selenium

Selenium WebDriver (often known as simply Selenium) is a multilanguage browser automation library. Selenium’s architecture is based on the W3C WebDriver standard, which defines a protocol for browser communication using JSON over HTTP.

Selenium has supported BiDi since version 4, with high-level APIs coming in Selenium 5. This way, currently both WebDriver and BiDi-based automation are possible with Selenium:

For enabling BiDi in Selenium you need:

@BeforeEach
void setup() {
    ChromeOptions options = new ChromeOptions();
    options.enableBiDi();
    driver = new ChromeDriver(options);
}

Once enabled, you can interact with BiDi modules like BrowsingContext, Input, Network, and Log.

Example: Browsing Context

@Test
void testBrowsing() {
    BrowsingContext context = new BrowsingContext(driver, driver.getWindowHandle());
    context.navigate("https://bonigarcia.dev/selenium-webdriver-java/");
    String screenshot = context.captureScreenshot(); // Base64 image
    assertThat(screenshot).isNotBlank();
}

Example: Listening to Logs

@Test
void testLog() {
    List<GenericLogEntry> logs = new ArrayList<>();
    try (LogInspector inspector = new LogInspector(driver)) {
        inspector.onConsoleEntry(logs::add);
    }
    driver.get("https://bonigarcia.dev/selenium-webdriver-java/console-logs.html");
    new WebDriverWait(driver, Duration.ofSeconds(5)).until(_ -> logs.size() > 3);
    logs.forEach(log -> System.out.println(log.getText()));
}

Puppeteer

Puppeteer is a Node.js browser automation library created and maintained by the Chrome DevTools team at Google since 2017. Puppeteer was initially tied to CDP, now supports BiDi for Firefox as of v23 — and uses it as the default protocol from Puppeteer 24 onward.

Example: Hello World with Puppeteer and BiDi

const puppeteer = require('puppeteer');

describe('Hello World with Puppeteer and BiDi', () => {
  let browser, page;

  beforeAll(async () => {
    browser = await puppeteer.launch({
      browser: 'firefox',
      protocol: 'webDriverBiDi',
    });
    page = await browser.newPage();
  });

  it('checks page title', async () => {
    await page.goto('https://bonigarcia.dev/selenium-webdriver-java/');
    const title = await page.title();
    expect(title).toContain('Selenium WebDriver');
  });

  afterAll(async () => await browser.close());
});java

Cypress

Cypress is a JavaScript end-to-end automated testing framework created as a company in 2014 to provide a seamless experience for automated web testing.

As of Cypress 14.1.0 (February 2025), Firefox automation runs over WebDriver BiDi by default. By Cypress 15 (August 2025), CDP support in Firefox was completely dropped.

Users don’t need to change a thing — BiDi runs transparently beneath the familiar Cypress API:

describe('Hello World Cypress', () => {
  it('checks title', () => {
    cy.visit('https://bonigarcia.dev/selenium-webdriver-java/');
    cy.title().should('include', 'Selenium WebDriver');
  });
});

Playwright

Playwright is a multilanguage end-to-end automated testing framework maintained by Microsoft since 2020. Playwright maintains patched versions of Chromium, Firefox, and WebKit (to enable automation and cross-browser consistency). Playwright uses an extended version of CDP to implement to control uniformly across these browsers.

Playwright is working toward BiDi integration (see issue). Although support is still experimental, the transition to WebDriver BiDi will likely happen automatically in a future version of Playwright once the protocol is mature enough to support all of Playwright’s features.

Conclusions

• WebDriver BiDi is an in-progress W3C standard for the next generation of browser automation
• It combines the stability of WebDriver with the power of CDP, offering a single, standard way to automate browsers
• Major tools like Selenium, Puppeteer, Cypress, and Playwright are actively integrating WebDriver BiDi
• Selenium: BiDi low-level features available in Selenium 4, high-level API is in development (planned for Selenium 5)
• Puppeteer: BiDi support for Firefox since v23
• Cypress: BiDi support for Firefox since v14.1.0
• Playwright: BiDi support is still experimental

How to track the evolution of WebDriver BiDi?

• W3C WebDriver issues
• W3C WebDriver BiDi roadmap
• W3C WebDriver BiDi planning
• WPT dashboard
• Implementation of WebDriver BiDi for Chromium
• Chrome for developers blog about BiDi
• Communication with the Firefox team about WebDriver BiDi

Introduction

A unit testing framework is a tool that provides structure and reusable components to write, organize, and run automated tests for given pieces of code, ensuring they behave as expected. This story reviews two of Java’s most popular unit testing frameworks: JUnit and TestNG.

JUnit

Created by Kent Beck and Erich Gamma in 1999, JUnit quickly became the de facto testing library for Java. Its evolution is as follows:

• JUnit 4: widespread adoption; annotation-based model (@Test, @Before, etc.)
• JUnit 5 (2017): major redesign including the JUnit Platform, the foundation of the JUnit 5 testing framework, providing the launching infrastructure for running tests and defining the API for test engines (like JUnit Jupiter or Vintage) to discover and execute tests.
• JUnit 6 (2025): the latest release (September 30, 2025), supporting Java 17 and cleaning up deprecated APIs

TestNG

Created by Cédric Beust in 2004, TestNG was designed to fix some of JUnit’s early limitations. Its key features include:

• Grouping and filtering via annotations
• Native parallel execution
• Built-in data providers for parameterized tests

Comparison

In this story, we’ll look at seven areas side-by-side:

1. Test lifecycle (basics)
2. Parameterized tests
3. Categorizing & filtering tests
4. Conditional test execution
5. Ordering tests
6. Parallel execution
7. Advanced test lifecycle

As a real use case, this comparison will be done using Selenium to illustrate the key differences between JUnit and TestNG. Selenium is a browser automation library, not a testing framework. However, the main use case of Selenium is end-to-end automated testing. For this reason, it is typically used in conjunction with a unit testing framework like JUnit or TestNG.

This story results from the work on developing examples of two books: Mastering Software Testing with JUnit 5 (Packt Publishing, 2017) and Hands-On Selenium WebDriver with Java (O’Reilly Media, 2022). The test examples are presented here in the following open-source repositories: mastering-junit5 and selenium-webdriver-java.

1. Test lifecycle (basics)

The test lifecycle is the sequence of steps a testing framework follows to set up the test fixture (initial state), execute the test(s), and clean up afterward. The following picture shows that the basic test lifecycle is similar in JUnit and TestNG, but with changes in the annotations’ names.

Example #1.1: basic test with Selenium — JUnit

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

class HelloWorldSeleniumJupiterTest {
     WebDriver driver;
     @BeforeEach
    void setup() {
        driver = new ChromeDriver();
    }
     @Test
    void test() {
        // Test logic
    }

    @AfterEach
    void teardown() {
        driver.quit();
    }
}

Example #1.2: basic test with Selenium — TestNG

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class HelloWorldSeleniumNGTest {
     WebDriver driver;
     @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
    }
     @Test
    public void test() {
        // Test logic
    }

    @AfterMethod
    public void teardown() {
        driver.quit();
    }
}

2. Parameterized tests

A parameterized test is a test that runs multiple times with different input values, allowing us to reuse the same logic across varied datasets.

To implement a parameterized test in JUnit, we need to:

• Use @ParameterizedTest (instead of @Test) or @ParameterizedClass (in addition to @Test)
• Use an argument provider (to define the dataset)

There are two ways of implementing parameterized tests in TestNG:

• Using @DataProvider (most common and scalable)
• Using @Parameters + testng.xml (dataset in <test></test>)

Example #2.1: data-driven test case with Selenium — JUnit

class LoginJupiterTest extends BrowserParent {
     static Stream<Arguments> loginData() {
        return Stream.of(Arguments.of("user", "user", "Login successful"),
                Arguments.of("bad-user", "bad-passwd", "Invalid credentials"));
    }

    @ParameterizedTest
    @MethodSource("loginData")
    void testLogin(String username, String password, String expectedText) {
        // Test logic
    }
}

Example #2.2: data-driven test case with Selenium — TestNG

public class LoginNGTest extends BrowserParent {
     @DataProvider(name = "loginData")
    public static Object[][] data() {
        return new Object[][] { { "user", "user", "Login successful" },
                { "bad-user", "bad-passwd", "Invalid credentials" } };
    }
     @Test(dataProvider = "loginData")
    public void testLogin(String username, String password, String expectedText) {
        // Test logic
    }
 }

Example #3.1: cross-browser testing with Selenium — JUnit

@ParameterizedClass
@ArgumentsSource(CrossBrowserProvider.class)
class CrossBrowserParent {
     @Parameter
    WebDriver driver;
     @AfterEach
    void teardown() {
        driver.quit();
    }
 }

class CrossBrowserProvider implements ArgumentsProvider {
     @Override
    public Stream<? extends Arguments> provideArguments(
            ExtensionContext context) {
        ChromeDriver chrome = new ChromeDriver();
        FirefoxDriver firefox = new FirefoxDriver();
         return Stream.of(Arguments.of(chrome), Arguments.of(firefox));
    }
 }

class CrossBrowserJUnitTest extends CrossBrowserParent {
     @Test
    void test() {
        // Test logic
    }
}

Example #3.2: cross-browser testing with Selenium — TestNG

public class CrossBrowserNGTest extends CrossBrowserParent {
     @Test(dataProvider = "browserProvider")
    public void test(WebDriver driver) {
        this.driver = driver;
         // Test logic
    }
 }

public class CrossBrowserParent {
     WebDriver driver;
     @DataProvider(name = "browserProvider")
    public static Object[][] data() {
        ChromeDriver chrome = new ChromeDriver();
        FirefoxDriver firefox = new FirefoxDriver();
         return new Object[][] { { chrome }, { firefox } };
    }
     @AfterMethod
    void teardown() {
        driver.quit();
    }
 }

3. Categorizing & filtering tests

Categorizing and filtering allows us to group tests into categories and run only the ones that match specific criteria.

In JUnit, test classes and methods can be tagged in JUnit using @Tag. In TestNG, test methods can be grouped using the attribute groups in @Test. Those categories (tags or groups) can later be used to filter test discovery and execution.

Example #5.1: grouping Selenium tests — JUnit

class CategoriesJUnitTest extends BrowserParent {
     @Test
    @Tag("WebForm")
    void testCategoriesWebForm() {
        // Test logic
    }
     @Test
    @Tag("HomePage")
    void testCategoriesHomePage() {
        // Test logic
    }
 }

mvn test -Dgroups=HomePage

gradle test -Pgroups=HomePage

Example #5.2: grouping Selenium tests — TestNG

public class CategoriesNGTest extends BrowserGroupsParent {
     @Test(groups = { "WebForm" })
    public void testCategoriesWebForm() {
        // Test logic
    }
     @Test(groups = { "HomePage" })
    public void tesCategoriestHomePage() {
        // Test logic
    }
}

mvn test -Dtest=CategoriesNGTest -DexcludedGroups=HomePage

gradle test --tests CategoriesNGTest -PexcludedGroups=HomePage

4. Conditional test execution

Conditional test execution allows us to enable or skip tests based on predefined conditions. JUnit provides a rich set of built-in annotations for skipping tests (@Disabled and others). Also, we can use Assumptions to disable tests in runtime. TestNG provides the annotation @Ignore and attributes in @Test (e.g., enabled=false) to run conditionally. Also, we can use SkipException to disable tests in runtime.

The JUnit annotations for disabling tests are the following:

Example #6.1: skipping tests (I) — JUnit

class DisabledJupiterTest {
    @Disabled("Optional reason for disabling")
    @Test
    public void testDisabled1() {
        // Test logic
    }
    @DisabledOnJre(JAVA_17)
    @Test
    public void testDisabled2() {
        // Test logic
    }
    @EnabledOnOs(MAC)
    @Test
    public void testDisabled3() {
        // Test logic
    }

}

Example #6.2: skipping tests (I) — TestNG

public class DisabledNGTest {
     @Ignore("Optional reason for disabling")
    @Test
    public void testDisabled1() {
        // Test logic
    }
     @Test(enabled = false)
    public void testDisabled2() {
        // Test logic
    }
 }

Example #7.1: skipping tests (II) — JUnit

class ConditionalJupiterTest {
     @Test
    public void testConditional() {
        boolean condition = false; // runtime condition
        Assumptions.assumeTrue(condition);
         // Test logic
    }
}

Example #7.2: skipping tests (II) — TestNG

public class ConditionalNGTest {
     @Test
    public void testConditional() {
        boolean condition = false; // runtime condition
        if (!condition) {
            throw new SkipException("Skipping test");
        }
         // Test logic
    }
 }

5. Ordering tests

Ordering tests is used to control the sequence in which tests are executed. The default order for test execution are:

• In JUnit, tests are run in an unspecified order (not guaranteed, deterministic algorithm that is but intentionally nonobvious meant to be independent)
• In TestNG, tests are run in alphabetical order by method name

To change this behavior:

• In JUnit, we use @TestMethodOrder with @Order.
• TestNG, we use priority and dependsOnMethods in @Test, or class order in testng.xml

Example #8.1: reuse the same browser to run tests in a given order — JUnit

@TestInstance(Lifecycle.PER_CLASS)
@TestMethodOrder(OrderAnnotation.class)
class OrderJunitTest {
    WebDriver driver;

    @BeforeAll
    void setup() {
        driver = new ChromeDriver();
    }

    @Test
    @Order(1)
    void testA() {
        // Test logic
    }

    @Test
    @Order(2)
    void testB() {
        // Test logic
    }

    @AfterAll
    void teardown() {
        driver.quit();
    }
}

Example #8.2: reuse the same browser to run tests in a given order — TestNG

public class OrderNGTest {
    WebDriver driver;

    @BeforeClass
    public void setup() {
        driver = new ChromeDriver();
    }

    @Test(priority = 1)
    public void testA() {
        // Test logic
    }

    @Test(priority = 2)
    public void testB() {
        // Test logic
    }

    @AfterClass
    public void teardown() {
        driver.quit();
    }
 }

6. Parallel execution

Parallel test execution allows us to run multiple tests simultaneously to speed up execution. JUnit provides different configuration parameters to tests in parallel:

• junit.jupiter.execution.parallel.enabled (to enable test parallelism)
• junit.jupiter.execution.parallel.mode.classes.default (to run test classes in parallel)
• junit.jupiter.execution.parallel.mode.default (to run test methods in parallel)

These parameters can be specified using a configuration file or in runtime trough annotations (@Execution).

On the ther hand, TestNG enables parallelism using the testng.xml config file.

Example #9.1: run Selenium tests in parallel — JUnit

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

@Execution(ExecutionMode.CONCURRENT)
class Parallel1JupiterTest extends BrowserParent {
    @Test
    void testParallel1() {
        // Test logic
    }
 }

@Execution(ExecutionMode.CONCURRENT)
class Parallel2JupiterTest extends BrowserParent {
    @Test
    void testParallel2() {
        // Test logic
    }
 }

Example #9.2: run Selenium tests in parallel — TestNG

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="parallel-suite" parallel="classes" thread-count="2">
    <test name="parallel-tests">
        <classes>
            <class name="io.github.bonigarcia.testng.selenium.HelloWorldSeleniumNGTest" />
            <class name="io.github.bonigarcia.testng.selenium.BasicSeleniumNGTest" />
        </classes>
    </test>
</suite>

7. Advanced test lifecycle

In JUnit 5+, the extension model provides comprehensive capabilities to customize and hook into the test lifecycle at various points.

The following diagram shows the JUnit 5+ test execution lifecycle and the order in which user-defined annotations and extension callbacks run. Callbacks are extension hooks, and annotations are user code methods executed around each test lifecycle.

On the other hand, TestNG provides a rich set of listeners to intercept lifecycle events for tests and suites:

Example #10.1: retrying Selenium tests (to detect flakiness) — JUnit

@ExtendWith(RetryExtension.class)
class RandomCalculatorJupiterTest extends BrowserParent {
    @Test
    void testRandomCalculator() {
        // Test logic
    }
 }

class RandomCalculatorJupiterTest extends BrowserParent {

    @RegisterExtension
    Extension failureWatcher = new RetryExtension(5);

    @Test
    void testRandomCalculator() {
        // Test logic
    }
 }

public class RetryExtension implements TestExecutionExceptionHandler {
    static final int DEFAULT_MAX_RETRIES = 3;
    final AtomicInteger retryCount = new AtomicInteger(1);
    final AtomicInteger maxRetries = new AtomicInteger(DEFAULT_MAX_RETRIES);

    public RetryExtension() {
        // Default constructor
    }

    public RetryExtension(int maxRetries) {
        this.maxRetries.set(maxRetries);
    }

    @Override
    public void handleTestExecutionException(ExtensionContext extensionContext,
            Throwable throwable) throws Throwable {
        // Manage throwable depending on the retry count
    }
 }

Example #10.2: retrying Selenium tests (to detect flakiness) — TestNG

public class RandomCalculatorNGTest extends BrowserParent {
    @Test(retryAnalyzer = RetryAnalyzer.class)
    @Retry(5)
    public void testRandomCalculator() {
        // Test logic
    }
 }

@Retention(RetentionPolicy.RUNTIME)
public @interface Retry {
    int value();
}

public class RetryAnalyzer implements IRetryAnalyzer {
    static final int DEFAULT_MAX_RETRIES = 3;
    final AtomicInteger retryCount = new AtomicInteger(1);

    @Override
    public boolean retry(ITestResult result) {
        Method method = result.getMethod().getConstructorOrMethod().getMethod();
        int maxRetries = DEFAULT_MAX_RETRIES;
        if (method.isAnnotationPresent(Retry.class)) {
            Retry retry = method.getAnnotation(Retry.class);
            maxRetries = retry.value();
        }
        if (retryCount.get() <= maxRetries) {
            logError(result.getThrowable());
            retryCount.incrementAndGet();
            return true;
        }
        return false;
    }

    private void logError(Throwable e) {
        System.err.println("Attempt test execution #" + retryCount.get()
                + " failed (" + e.getClass().getName() + "thrown):  "
                + e.getMessage());
    }
 }

Example #11.1: gather data (e.g., browser screenshot) if test fails — Java

@ExtendWith(FailureWatcher.class)
class FailureJupiterTest extends BrowserParent {
    @Test
    void testFailure() {
        // Test logic
        fail("Forced error");
    }
 }

public class FailureWatcher implements TestExecutionExceptionHandler {
    @Override
    public void handleTestExecutionException(ExtensionContext context,
            Throwable throwable) throws Throwable {
         context.getTestInstance().ifPresent(testInstance -> {
            WebDriver driver = (WebDriver) SeleniumUtils
                    .getFieldFromTestInstance(testInstance, "driver");
            SeleniumUtils.getScreenshotAsFile(driver, context.getDisplayName());
        });
         throw throwable;
    }
}

Example #11.2: gather data (e.g., browser screenshot) if test fails — TestNG

public class FailureNGTest {
    WebDriver driver;

    @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
    }

    @AfterMethod
    public void teardown(ITestResult result) {
        if (result.getStatus() == ITestResult.FAILURE) {
            SeleniumUtils.getScreenshotAsFile(driver, result.getName());
        }
         driver.quit();
    }

    @Test
    public void testFailure() {
        // Test logic
        fail("Forced error");
    }
 }

Example #12.1: reporting test suite — Java

@ExtendWith(Reporter.class)
class Report1JupiterTest extends BrowserParent {
    @Test
    void testReport1() {
        // Test logic
    }
 }

@ExtendWith(Reporter.class)
class Report2JupiterTest extends BrowserParent {
    @Test
    void testReport2() {
        // Test logic
    }
 }

public class Reporter implements BeforeAllCallback, BeforeEachCallback,
        AfterTestExecutionCallback {
    static final String REPORT_NAME = "report-junit.html";
    ExtentReports report;
    ExtentTest test;

    @Override
    public void beforeAll(ExtensionContext context) throws Exception {
        Store store = context.getRoot()
                .getStore(ExtensionContext.Namespace.create(STORE_NAMESPACE));
        report = store.get(STORE_NAME, ExtentReports.class);
        if (report == null) {
            report = new ExtentReports();
            store.put(STORE_NAME, report);
             Runtime.getRuntime().addShutdownHook(new Thread(report::flush));
        }
        ExtentSparkReporter htmlReporter = new ExtentSparkReporter(REPORT_NAME);
        report.attachReporter(htmlReporter);
    }

    @Override
    public void beforeEach(ExtensionContext context) throws Exception {
        test = report.createTest(context.getDisplayName());
    }

    @Override
    public void afterTestExecution(ExtensionContext context) throws Exception {
        context.getTestInstance().ifPresent(testInstance -> {
            // Take screenshot 
            test.addScreenCaptureFromBase64String(screenshot);
        });
    }
 }

Example #12.2: reporting test suite — TestNG

@Listeners(Reporter.class)
public class Report1NGTest extends BrowserParent {
    @Test
    public void testReport1() {
        // Test logic
    }
 }

@Listeners(Reporter.class)
public class Report2NGTest extends BrowserParent {
    @Test
    public void testReport2() {
        // Test logic
    }
 }

public class Reporter implements ITestListener {
     static final String REPORT_NAME = "report-testng.html";
    ExtentReports report;
    ExtentTest test;

    @Override
    public void onStart(ITestContext context) {
        ITestListener.super.onStart(context);
        report = new ExtentReports();
        ExtentSparkReporter htmlReporter = new ExtentSparkReporter(REPORT_NAME);
        report.attachReporter(htmlReporter);
    }

    @Override
    public void onTestStart(ITestResult result) {
        ITestListener.super.onTestStart(result);
        test = report.createTest(result.getName());
    }

    @Override
    public void onTestSuccess(ITestResult result) {
        ITestListener.super.onTestSuccess(result);
        // Take screenshot 
        test.addScreenCaptureFromBase64String(screenshot);
    }

    @Override
    public void onFinish(ITestContext context) {
        ITestListener.super.onFinish(context);
        report.flush();
    }
 }

Conclusions

Both JUnit and TestNG provide a comprehensive programming model for developing advanced tests in Java. The similar aspects in JUnit and TestNG are the following:

• Basic test lifecycle
• Categorizing and filtering tests
• Ordering tests
• Parallel test execution

The strong points of JUnit are:

• Parameterized tests
• Conditional test execution
• Extension model

The strong points in TestNG is:

• Test listeners

What is Browser Automation?

Browser automation is the process of using software or scripts to control a web browser and perform tasks automatically, without manual human intervention. The primary use cases for browser automation include:

• Test automation: This is the most common application, encompassing end-to-end testing to verify web applications.
• Web scraping: Automating the extraction of large amounts of data from websites.
• Automating repetitive tasks for web pages: Automating mundane tasks like filling out forms or generating reports from web interfaces.

The world of browser automation is rich with tools, each with its own philosophy and strengths. Some of the key players include Selenium, Playwright, Cypress, Puppeteer, TestCafe, and WebdriverIO. This story focuses on the most prominent choices for Java developers: Selenium and Playwright.

Selenium

Selenium is a browser automation library, and it has been considered the de facto standard for browser automation for many years. Selenium is:

• Multi-language: Officially supported in Java, JavaScript, Python, .NET, and Ruby.
• Cross-browser: Compatible with all major browsers like Chrome, Firefox, Safari, and Edge.
• Open-source and community-driven since 2004.

Selenium’s architecture is based on the W3C WebDriver standard, which defines a protocol for browser communication using JSON over HTTP. This standards-based approach is a key strength, ensuring broad compatibility.

It’s important to understand that Selenium is not a testing framework because it doesn’t include a test runner, assertion library, or reporting features. For this, Selenium users relies on a rich ecosystem of tools like JUnit or TestNG (unit testing frameworks), AssertJ (fluent assertions), or Allure and ExtentReports (reporting), among others.

Selenium Manager

A significant recent improvement is Selenium Manager. Shipped with Selenium out of the box, it automatically discovers, downloads, and caches the browser drivers required for automation (e.g., chromedriver for Chrome, geckodriver for Firefox, etc.), greatly simplifying project setup. Consider the following test example. Internally, Selenium is using Selenium Manager to discover, download, and cache the needed driver, geckodriver, in this example:

import static org.assertj.core.api.Assertions.assertThat;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;

class HelloWorldFirefoxJupiterTest {

    WebDriver driver;

    @BeforeEach
    void setup() {
        driver = new FirefoxDriver();
    }

    @AfterEach
    void teardown() {
        driver.quit();
    }

    @Test
    void test() {
        driver.get("https://bonigarcia.dev/selenium-webdriver-java/");
        assertThat(driver.getTitle()).contains("Selenium WebDriver");
    }

}

Moreover, Selenium Manager also automatically discovers, downloads, and caches the browsers driven with Selenium. For example, if Firefox is unavailable in the previous test, Selenium Manager will manage (discover, download, and cache) the latest version of Firefox. And in addition, specific browser versions can be specified as follows (including “beta”, “dev”, or “nightly”), for example, as follows:

import static org.assertj.core.api.Assertions.assertThat;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

class ChromeVersionTest {

    WebDriver driver;

    @BeforeEach
    void setup() {
        ChromeOptions options = new ChromeOptions();
        options.setBrowserVersion("beta");
        driver = new ChromeDriver(options);
    }

    @Test
    void test() {
        driver.get("https://bonigarcia.dev/selenium-webdriver-java/");
        String title = driver.getTitle();
        assertThat(title).contains("Selenium WebDriver");
    }

    @AfterEach
    void teardown() {
        driver.quit();
    }

}

Selenium-Java Ecosystem

A key strength for developing end-to-end tests with Selenium and Java is the richness of their respective ecosystem. The following examples demonstrate how. For instance, to implement cross-browser testing (i.e., reuse the same test logic for different browsers), we can use the parameterized test support by JUnit, as follows (see complete example here):

import static org.assertj.core.api.Assertions.assertThat;
import org.junit.jupiter.api.Test;

class CrossBrowserTest extends CrossBrowserParent {

    @Test
    void test() {
        driver.get("https://bonigarcia.dev/selenium-webdriver-java/");
        assertThat(driver.getTitle()).contains("Selenium WebDriver");
    }

}

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.params.Parameter;
import org.junit.jupiter.params.ParameterizedClass;
import org.junit.jupiter.params.provider.ArgumentsSource;
import org.openqa.selenium.WebDriver;

@ParameterizedClass
@ArgumentsSource(CrossBrowserProvider.class)
class CrossBrowserParent {

    @Parameter
    WebDriver driver;

    @AfterEach
    void teardown() {
        driver.quit();
    }

}

import java.util.stream.Stream;
import org.junit.jupiter.api.extension.ExtensionContext;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.ArgumentsProvider;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;

public class CrossBrowserProvider implements ArgumentsProvider {

    @Override
    public Stream<? extends Arguments> provideArguments(
            ExtensionContext context) {
        ChromeDriver chrome = new ChromeDriver();
        FirefoxDriver firefox = new FirefoxDriver();

        return Stream.of(Arguments.of(chrome), Arguments.of(firefox));
    }

}

For video recording, you can use WebDriverManager, both using browsers in Docker containers (example) or by using a web extension called BrowerWatcher to record only the viewport (example).

import static org.assertj.core.api.Assertions.assertThat;
import java.time.Duration;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.WebDriver;
import io.github.bonigarcia.wdm.WebDriverManager;

class DockerChromeRecordingTest {

    WebDriver driver;
    WebDriverManager wdm;

    @BeforeEach
    void setupTest() {
        wdm = WebDriverManager.chromedriver().browserInDocker()
                .enableRecording();
        driver = wdm.create();
    }

    @Test
    void test() {
        driver.get("https://bonigarcia.dev/selenium-webdriver-java/");
        assertThat(driver.getTitle()).contains("Selenium WebDriver");
    }

    @AfterEach
    void teardown() throws InterruptedException {
        // FIXME: pause for manual browser inspection
        Thread.sleep(Duration.ofSeconds(3).toMillis());
        wdm.quit();
    }

}

import java.nio.file.Path;
import java.time.Duration;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.slf4j.Logger;
import io.github.bonigarcia.wdm.WebDriverManager;

class RecordEdgeTest {

    WebDriver driver;
    WebDriverManager wdm;

    @BeforeEach
    void setup() {
        wdm = WebDriverManager.edgedriver().watch();
        driver = wdm.create();
    }

    @AfterEach
    void teardown() {
        driver.quit();
    }

    @Test
    void test() {
        driver.get(
                "https://bonigarcia.dev/selenium-webdriver-java/slow-calculator.html");

        wdm.startRecording();

        // 1 + 3
        driver.findElement(By.xpath("//span[text()='1']")).click();
        driver.findElement(By.xpath("//span[text()='+']")).click();
        driver.findElement(By.xpath("//span[text()='3']")).click();
        driver.findElement(By.xpath("//span[text()='=']")).click();

        // ... should be 4, wait for it
        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
        wait.until(ExpectedConditions.textToBe(By.className("screen"), "4"));

        wdm.stopRecording();

        Path recordingPath = wdm.getRecordingPath();
        assertThat(recordingPath).exists();
    }

}

Playwright

Playwright is a newer, modern alternative from Microsoft that has quickly gained popularity. Like Selenium, it is open-source, multi-language and cross-browser. We can define Playwright as follows:

• For Node.js, Playwright is a end-to-end testing framework.
• For Java, Python, and .NET, Playwright is a browser automation library.

The difference is caused by the Playwright Test Runner (@playwright/test), a full-featured testing framework bundled with Playwright in Node.js, so it is only available for JavaScript/TypeScript developers. The Playwright Test runner provides the following features:

• Test runner and assertions (similar to JUnit/TestNG)
• Built-in fixtures (browser/page/context lifecycle)
• Parallel test execution across multiple browsers/devices
• Retries mechanism
• HTML reporting
• Video capture when failures
• API testing (built-in request fixture)
• Visual comparisons (expect(page).toHaveScreenshot())
• Component testing (for React/Vue/Svelte/Angular)

Regarding its architecture, Playwright takes a different architectural approach than Selenium. It maintains its own patched versions of Chromium, Firefox, and WebKit and it uses internally an extended version of the Chrome DevTools Protocol (CDP) and a custom WebSocket-based protocol to control these browsers uniformly.

This way, for creating complete end-to-end tests with Playwright and Java, we typically use the Playwright API plus other tools, such as a unit testing framework (e.g., JUnit, TestNG), reporting tools, etc. For example:

import static org.assertj.core.api.Assertions.assertThat;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import com.microsoft.playwright.Browser;
import com.microsoft.playwright.Page;
import com.microsoft.playwright.Playwright;

class HelloWorldPlaywrightTest {

    Browser browser;
    Page page;

    @BeforeEach
    void setup() {
        browser = Playwright.create().chromium().launch();
        page = browser.newContext().newPage();
    }

    @Test
    void test() {
        page.navigate("https://bonigarcia.dev/selenium-webdriver-java/");
        String title = page.title();
        assertThat(title).contains("Selenium WebDriver");
    }

    @AfterEach
    void teardown() {
        browser.close();
    }

}

Advanced features

One of the most attractive features of Playwright compared to Selenium is its built-in automatic waiting mechanism. Playwright intelligently waits for elements to be ready before performing actions, such as clicking or typing, removing the need for explicit waits. The following test illustrates this feature:

import static org.assertj.core.api.Assertions.assertThat;
import java.nio.file.Paths;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import com.microsoft.playwright.Browser;
import com.microsoft.playwright.BrowserType;
import com.microsoft.playwright.Page;
import com.microsoft.playwright.Playwright;

class SlowLoginPlaywrightTest {

    Browser browser;
    Page page;

    @BeforeEach
    void setup() {
        browser = Playwright.create().chromium()
                .launch(new BrowserType.LaunchOptions().setHeadless(false));
        page = browser.newContext().newPage();
    }

    @Test
    void test() {
        // Open system under test (SUT)
        page.navigate(
                "https://bonigarcia.dev/selenium-webdriver-java/login-slow.html");

        // Log in
        page.fill("#username", "user");
        page.fill("#password", "user");
        page.click("button[type='submit']");

        // Assert expected text
        String successText = page.textContent("#success");
        assertThat(successText).contains("Login successful");

        // Take screenshot
        page.screenshot(new Page.ScreenshotOptions()
                .setPath(Paths.get("slow-login-playwright.png")));
    }

    @AfterEach
    void teardown() {
        browser.close();
    }

}

Another appealing feature of Playwright is the trace viewer, a powerful debugging tool that lets you replay your test execution step by step. It records snapshots, network activity, console logs, and DOM states during a test run, allowing you to visually inspect what happened at each point and easily identify the cause of failures. For example:

import static org.assertj.core.api.Assertions.assertThat;
import java.nio.file.Paths;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import com.microsoft.playwright.Browser;
import com.microsoft.playwright.BrowserType;
import com.microsoft.playwright.Page;
import com.microsoft.playwright.Playwright;

class SlowLoginPlaywrightTest {

    Browser browser;
    Page page;

    @BeforeEach
    void setup() {
        browser = Playwright.create().chromium()
                .launch(new BrowserType.LaunchOptions().setHeadless(false));
        page = browser.newContext().newPage();
    }

    @Test
    void test() {
        // Open system under test (SUT)
        page.navigate(
                "https://bonigarcia.dev/selenium-webdriver-java/login-slow.html");

        // Log in
        page.fill("#username", "user");
        page.fill("#password", "user");
        page.click("button[type='submit']");

        // Assert expected text
        String successText = page.textContent("#success");
        assertThat(successText).contains("Login successful");

        // Take screenshot
        page.screenshot(new Page.ScreenshotOptions()
                .setPath(Paths.get("slow-login-playwright.png")));
    }

    @AfterEach
    void teardown() {
        browser.close();
    }

}

Video recording is another built-in feature in Playwright for Java, for example, as follows:

import static org.assertj.core.api.Assertions.assertThat;
import java.nio.file.Paths;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import com.microsoft.playwright.Browser;
import com.microsoft.playwright.BrowserType;
import com.microsoft.playwright.Page;
import com.microsoft.playwright.Playwright;

class RecordingSlowLoginPlaywrightTest {

    Browser browser;
    Page page;

    @BeforeEach
    void setup() {
        browser = Playwright.create().chromium()
                .launch(new BrowserType.LaunchOptions().setHeadless(false));
        Browser.NewContextOptions options = new Browser.NewContextOptions()
                .setRecordVideoDir(Paths.get("."));
        page = browser.newContext(options).newPage();
    }

    @Test
    void test() {
        // Open system under test (SUT)
        page.navigate(
                "https://bonigarcia.dev/selenium-webdriver-java/login-slow.html");

        // Log in
        page.fill("#username", "user");
        page.fill("#password", "user");
        page.click("button[type='submit']");

        // Assert expected text
        String successText = page.textContent("#success");
        assertThat(successText).contains("Login successful");
    }

    @AfterEach
    void teardown() {
        browser.close();
    }

}

Conclusions

Selenium and Playwright cannot be directly compared since they are naturally different. The following table summarizes their key differences:

Finally, we can find both pros and cons in Selenium and Playwright in Java, namely:

WebDriverManager was first released on 19 March 2015. At that time, Selenium was in version 2 (i.e., the first release of “Selenium WebDriver”), and it was considered a “non-batteries included” library. That means that, to control a browser programmatically with Selenium (such as Chrome or Firefox), Selenium users first should manage (i.e., download, setup, and maintain) the required drivers by Selenium (e.g., chromedriver for Chrome or geckodriver for Firefox) manually.

I found that manual process suboptimal. I used to think that, in an ideal world for browser automation, the driver management process should be automated. I looked for a solution to that, but I did not find any tool doing this. At the same time, I was working as a first-year lecturer at the university. I was chosen to give a course on “web programming.” Since Selenium was an important part of my career (I have used Selenium RC in my PhD dissertation and Selenium WebDriver in my research activities), I prepared a lecture about automated web testing using JUnit 4 and Selenium 2. But I didn’t like the driver thing. I wanted my students to go directly to the point and start playing with Selenium without wasting their energy in the driver setup. So, I created WebDriverManager 1.0.0 and recommended my students to use it.

In the following years, and thanks to the power of open source, WebDriverManager started to be used by others. I felt that WebDriverManager was addressing a real need of Selenium developers since the project began to grow, and people contributed to the WebDriverManager repo with pull requests, bug fixes, comments, etc. Moreover, the WebDriverManager concept was migrated from Java to other languages like webdriver-manager for JavaScript, webdriver-manager for Python, or WebDriverManager.Net for C#. This way, I have continued maintaining and incorporating more and more features to WebDriverManager in my leisure time since then. Nowadays, WebDriverManager is a well-known Java library used by hundreds of thousands of projects, with around 3 million downloads monthly in Maven Central.

WebDriverManager 6

To celebrate the 10th birthday of the project, WebDriverManager 6 has been released on 19 March 2025. This new major feature ships some important novelties.

Support to docker-selenium

One of the most relevant features shipped in WebDriverManager 5 was the ability to create browsers in Docker containers out of the box. To support this feature, WebDriverManager used the Docker images by WebDriverManager created and maintained by Aerokube. Unfortunately, these images have not been available since December 2024. Luckily, we have docker-selenium, a project maintained by Selenium that provides Docker images for running Selenium tests in containers. I have always wanted to support docker-selenium in WebDriverManager, but the lack of time stopped me. However, the sudden unavailability of Aerokube’s images forced me to migrate to docker-selenium quickly.

Luckily, the WebDriverManager API is the same after this significant change. Appealing features, such as browser recording, noVNC access, or unstable versions (i.e., beta and dev releases), are still supported. Even better, WebDriverManager supports ARM64 Docker images with docker-selenium thanks to the seleniarm images.

Improved browser version discovery

Browser version discovery was a key feature first introduced in WebDriverManager 3. Knowing the local browser version is key to selecting the proper driver version. To that aim, WebDriverManager has an internal knowledge database to discover browser versions using shell commands (e.g., google-chrome --version for Chrome in Linux).

WebDriverManager used WMIC (Windows Management Instrumentation Command-line) in Windows for browser version discovery. However, Microsoft announced that WMIC is deprecated as of Windows 10, version 21H1, and will be removed in a future version. Therefore, WebDriverManger 6 started to use PowerShell commands to discover browser versions. This feature is transparent for end-users, and it will guarantee that automated driver management will continue adequately in the upcoming years.

Finally, WebDriverManager 6 included a new API method called .browserBinary() to provide a better configuration capability regarding browser version discovery. This method allows the specification of the browser binary path used for driver version discovery.

As usual, this feature can also be configured using Java properties per the different browsers: wdm.chromeBinary, wdm.operaBinary, wdm.edgeBinary, wdm.firefoxBinary, and wdm.chromiumBinary.

Support to snap browsers/drivers

Some browsers, like Firefox and Chromium, are distributed through a packaging and deployment system called snap. Snap packages are self-contained and sandboxed, including all the dependencies required to run the application. For browsers, that means that both the browser and the driver are included in the snap package. As of release 6, WebDriverManager can detect if the local browser has been installed using snap, using the proper driver (which should be already locally installed). Again, this feature is transparent for WebDriverManager users. If the browser and driver are available, it can be used automatically in a Selenium session managed by WebDriverManager.

Selenium Manager

But wait. What about Selenium Manager? Is it not the same than WebDriverManager? Let me explain the little history of Selenium Manager.

In 2021, the Selenium project published the results of the first official Selenium survey. One of the key findings in this study was that Selenium users wanted “batteries included.” In other words, they want Selenium to manage browsers and drivers, similarly to the features provided by WebDriverManager. This way, I joined Sauce Labs as a Staff Software Engineer in the Open Source Program Office from 2022 to 2023 and contributed to the Selenium project, particularly developing Selenium Manager. Selenium Manager has been developed in Rust following the lessons learned from WebDriverManager, implementing the same driver resolution algorithm first designed in WebDriverManager. Selenium Manager is fully integrated into Selenium and is used by all the official binding languages: Java, JavaScript, Python, Ruby, and .Net. As shown in its usage statistics (publicly available through Plausible), Selenium Manager is used daily by hundreds of thousands of unique users worldwide. So, below, you can find some differences between WebDriverManager and Selenium Manager.

Is Selenium Manager a replacement for WebDriverManager? For the use case of automated driver management, yes. In other words, if you use WebDriverManager only for driver management, you can safely switch to Selenium Manager.

What are the key differences between WebDriverManager and Selenium Manager? Both projects provide automated driver management (chromedriver, geckodriver, etc.). However, WebDriverManager ships several unavailable features in Selenium Manager (e.g., self-managed browsers in Docker containers or custom monitoring features). On the other side, Selenium Manager provides automated browser management using the browser binary distributions for Windows, macOS, and Linux (e.g., based on Chrome for Testing).

What are the reasons to continue using WebDriverManager? There can be different reasons, such as:

• Advanced features. WebDriverManager provides self-managed browsers in Docker containers (now through docker-selenium). This feature allows you to delegate all the browser infrastructure management (including dev and beta browser releases) to WebDriverManager with Docker. Also, it enables the screencasting of Selenium sessions, which can be a game-changing characteristic for failure analysis (troubleshooting). Besides, WebDriverManager provides custom monitoring features (through BrowserWatcher), such as seamless console log gathering, Content Security Policy (CSP) disabling, or viewport screencasting (i.e., not record the whole desktop but only the browser viewport).
• Rich configuration. One of the key aspects of WebDriverManager is that all these features can be configured through its API, using Java system properties and even environmental variables. These capabilities are very convenient for fine-tuning every feature provided by WebDriverManager, such as automated driver management, docker management, or browser monitoring.
• Legacy support. The minimum version for the latest releases of Selenium 4 (i.e., those that have Selenium Manager) is Java 11. If you cannot bump to Java 11 yet (you should, but sometimes it is impossible), you can continue using WebDriverManager since even release 6 is compiled using Java 8.

What’s coming next

I’m devoted to maintaining Selenium Manager and WebDriverManager in the upcoming years. Now I am part of the Selenium Technical Leadership Committee (TLC), so my commitment is to continue improving the browser automation experience for Selenium users. Selenium Manager is still in beta but has already proven stable at this writing so that it will be released as stable in the upcoming Selenium 5. Also, in light of usage numbers, WebDriverManager is still a popular and helpful tool, so I will continue maintaining the project for the Java community.

WebDriverManager is an open-source Java library that carries out the management (i.e., download, setup, and maintenance) of the drivers required by Selenium WebDriver (e.g., chromedriver, geckodriver, msedgedriver, etc.) in a fully automated manner.

WebDriverManager enables the development of portable WebDriver tests while reducing the development and maintenance efforts. For instance, the skeleton of a JUnit 5 test using Selenium WebDriver and WebDriverManager is as follows:

WebDriverManager implements a resolution algorithm for automated driver management. The foundations of this algorithm are:

1. Browser version discovery.
2. Driver version match.
3. Driver and resolution cache.
4. Export driver path as system property setup.

You can find all the internal details of this resolution algorithm in the paper Automated driver management for Selenium WebDriver, published in the Springer Journal of Empirical Software Engineering in 2021.

WebDriverManager 5: the next generation

WebDriverManager was first released in 2015. Nowadays, it is a well-known helper library for Selenium WebDriver, used in thousands of projects. WebDriverManager 5 was released in 2021. As usual, this release allows the automated driver management for Selenium WebDriver. Moreover, this release provides other features aimed to ease the development of Selenium WebDriver tests.

New documentation

The documentation has been completely rewritten in WebDriverManager 5:

https://bonigarcia.dev/webdrivermanager/

Internally, this site is done in AsciiDoc, and it is generated to HTML, PDF, and EPUB.

Browser finder

As of version 5, WebDriverManager allows detecting if a given browser is installed or not in the local system. To this aim, each manager provides the method getBrowserPath(). This method returns an Optional<Path>, which is empty if a given browser is not installed in the system or the browser path (within the optional object) when detected. You can use this feature to skip tests using assumptions, for instance, as follows:

WebDriver builder

WebDriverManager 5 also allows instantiating WebDriver objects (e.g., ChromeDriver, FirefoxDriver, etc.) using the WebDriverManager API. This feature is available using the method create() of each manager. For instance:

Browsers in Docker

Another relevant new feature available in WebDriverManager 5 is the ability to create browsers in Docker containers out of the box. To use it, we need to invoke the method browserInDocker() in conjunction with create() of a given manager. For instance:

The usfed Docker images by WebDriverManager have been created and maintained by Aerokube. Therefore, Chrome (desktop and mobile), Firefox, Edge, Opera, and Safari (WebKit engine) are the available browsers to be executed as Docker containers in WebDriverManager. In addition, we can use the beta and development versions of Chrome and Firefox, thanks to a fork of the Aerokube images maintained by Twilio.

WebDriverManager allows connecting to the remote desktop session simply invoking the method enableVnc() of a dockerized browser. In addition, we can use the method enableRecording() to record the browser session.

Other usages

WebDriverManager can be used as a CLI tool, Java agent, or Selenium Server. Take a look at the documentation for further details:

https://bonigarcia.dev/webdrivermanager/

Selenium-Jupiter

WebDriverManager is the foundation tool of Selenium-Jupiter, an open-source JUnit 5 extension for developing Selenium WebDriver tests. Thanks to the parameter resolution provided by JUnit 5, the required boilerplate of a WebDriver test is reduced to the minimum.

Selenium-Jupiter also provides seamless integration with Docker, recordings, VNC, and more. Check out the documentation for the complete reference and examples:

https://bonigarcia.dev/selenium-jupiter