Running a Java Playwright Test on GitHub Actions

Pradap Pandiyan
5 min readFeb 23, 2025

--

In modern continuous integration pipelines, automated browser testing is key to catching UI regressions early. In this article, we’ll create a Java Playwright project using Maven, write sample tests with JUnit, and configure GitHub Actions to run these tests inside a Docker container. We’ll use the official Playwright image for Java — mcr.microsoft.com/playwright/java:v1.49.0-noble – to provide a consistent, preconfigured environment.

Setting Up Your Java Playwright Project

Project Structure

A typical Maven project for a Playwright might have the following structure:

playwright-java/
├── pom.xml
└── src
└── test
└── java
└── org
└── example
└── playwright
└── playwrightjava
└── TestExample.java

The pom.xml File

Your pom.xml file defines the dependencies and build configuration for your project. Here’s an example that includes Playwright and JUnit 5:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.example.playwright</groupId>
<artifactId>playwright-java</artifactId>
<version>1.0-SNAPSHOT</version>
<name>playwright-java</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.source>11</maven.compiler.source>
<junit.version>5.11.3</junit.version>
</properties>
<dependencies>
<dependency>
<groupId>com.microsoft.playwright</groupId>
<artifactId>playwright</artifactId>
<version>1.49.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

This file sets Java 11 as the target and includes Playwright (version 1.49.0) as well as JUnit dependencies for testing.

Writing Your Playwright Tests

Below is a sample test class (TestExample.java) that demonstrates three test scenarios:

  • Clicking a button and verifying a script-set variable.
  • Checking a checkbox.
  • Searching on Wikipedia.
package org.example.playwright.playwrightjava;
import com.microsoft.playwright.*;
import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
public class TestExample {
static Playwright playwright;
static Browser browser;
BrowserContext context;
Page page;
@BeforeAll
static void launchBrowser() {
playwright = Playwright.create();
browser = playwright.chromium().launch(new BrowserType.LaunchOptions().setHeadless(true));
}
@AfterAll
static void closeBrowser() {
playwright.close();
}
@BeforeEach
void createContextAndPage() {
context = browser.newContext();
page = context.newPage();
}
@AfterEach
void closeContext() {
context.close();
}
@Test
void shouldClickButton() {
page.navigate("data:text/html,<script>var result;</script><button onclick='result=\"Clicked\"'>Go</button>");
page.locator("button").click();
assertEquals("Clicked", page.evaluate("result"));
}
@Test
void shouldCheckTheBox() {
page.setContent("<input id='checkbox' type='checkbox'></input>");
page.locator("input").check();
assertTrue((Boolean) page.evaluate("() => document.getElementById('checkbox').checked"));
}
@Test
void shouldSearchWiki() {
page.navigate("https://www.wikipedia.org/");
page.locator("input[name=\"search\"]").click();
page.locator("input[name=\"search\"]").fill("playwright");
page.locator("input[name=\"search\"]").press("Enter");
assertEquals("https://en.wikipedia.org/wiki/Playwright", page.url());
}
}

What This Test Does

  • Browser Setup:
    The browser is launched once before all tests run, and a new browser context is created for each test to ensure isolation.
  • Test Scenarios:
    Each test performs a simple interaction: clicking a button, checking a checkbox, or performing a search on Wikipedia. Assertions verify that the actions have the expected outcomes.

Configuring GitHub Actions with a Docker Container

To ensure your tests run in a consistent environment, GitHub Actions can use a Docker container. The official image mcr.microsoft.com/playwright/java:v1.49.0-noble comes preconfigured with Java and Playwright dependencies.

The GitHub Actions Workflow File

Create a file named .github/workflows/ci.yml in your repository with the following content:

name: Java Playwright CI

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/playwright/java:v1.49.0-noble

steps:
- name: Checkout repository
uses: actions/checkout@v3

- name: Build project dependencies classpath
run: mvn dependency:build-classpath -Dmdep.outputFile=cp.txt

- name: Install Playwright Browsers
run: |
# Use the built classpath to run the CLI install command
java -cp "$(cat cp.txt)" com.microsoft.playwright.CLI install

- name: Run Tests
run: mvn test

How This Workflow Works

1. Checkout Repository

- name: Checkout repository
uses: actions/checkout@v3

What It Does:
This step uses the official actions/checkout action to clone your repository into the GitHub Actions runner. It makes your code available for subsequent steps in the workflow.

2. Build Project Dependencies Classpath

- name: Build project dependencies classpath
run: mvn dependency:build-classpath -Dmdep.outputFile=cp.txt

What It Does:
This Maven command builds a complete classpath of all your project dependencies and writes it to a file named cp.txt.

  • Why: The Playwright CLI requires access to all its dependencies when running. By building the classpath explicitly, you ensure that the Java command can locate the necessary classes.
  • How: The mvn dependency:build-classpath goal collects all the dependencies from your pom.xml and writes them in a format that the Java runtime can use.

3. Install Playwright Browsers

- name: Install Playwright Browsers
run: |
java -cp "$(cat cp.txt)" com.microsoft.playwright.CLI install

What It Does:
This step installs the browser binaries that Playwright needs to run tests.

  • Command Breakdown:
  • java -cp "$(cat cp.txt)": The -cp flag sets the classpath for the Java runtime. The command $(cat cp.txt) reads the content of cp.txt (which contains all your project dependencies).
  • com.microsoft.playwright.CLI install: This runs the Playwright CLI with the install argument, triggering the download and setup of browser binaries.
  • Why: Without installing these browsers, Playwright tests wouldn’t be able to run, since they require a browser environment to execute the tests.

4. Run Tests

- name: Run Tests
run: mvn test

What It Does:
This final step runs the test suite defined in your project.

  • How: The mvn test command compiles your test code and executes all tests (using JUnit in this case).
  • Outcome: You’ll see the results of your Playwright tests in the GitHub Actions logs, allowing you to verify that your application behaves as expected.
  1. Push Your Code:
    Initialize your Git repository (if not already initialized), commit your changes, and push to GitHub:

Monitor the Workflow:
After pushing your code, navigate to the Actions tab in your GitHub repository. You’ll see the “Java Playwright CI” workflow running. Click on the job to monitor the output. The logs will show the Maven build and test results.

  1. Troubleshooting:
    If a test fails or if there are environment issues, review the logs provided by GitHub Actions. The container image usually contains everything required for Playwright tests, but you may need to adjust timeouts or browser settings depending on your tests’ needs.

Conclusion

In this article, we set up a Java Playwright testing project using Maven and demonstrated how to run tests on GitHub Actions using a preconfigured Docker container. This approach not only ensures a consistent testing environment but also integrates automated UI testing into your continuous integration pipeline.

By following these steps, you can further expand your test suite, integrate with additional tools, and maintain robust, automated UI testing across your projects.

I have created a project on GitHub and added the code here.

Also, I have kept the job public on Github Actions in case you guys want to check the implementation here.

Feel free to hit clap if you like the content. Happy Automation Testing :) Cheers. 👏

--

--

Pradap Pandiyan
Pradap Pandiyan

Written by Pradap Pandiyan

I’m a passionate QA Engineer. I’m a motovlogger, content creator, off-roader and freelancer. Buy me a coffee here https://www.buymeacoffee.com/pradappandiyan

No responses yet