Best Playwright Tools, by the Job They Do

TL;DR

Start with Currents if you run a sharded, retried Playwright suite in CI: Currents' Test Explorer shows how a test's flakiness has changed between two equal time periods. Currents Test Orchestrator balances the load using historical execution data.

1. If you run a sharded, retried Playwright suite in CI, start with Currents.
2. If you want an interactive report with grouping and fast filtering, choose Monocart Reporter.
3. If you need automated results traced back to Jira requirements and stories, choose Xray.
4. If you need mobile devices, choose BrowserStack Automate.
5. If you want open-source visual review, choose Argos.

Your Playwright suite runs in CI, the build is green, and the test that failed twice this week looks fine in the latest report. Playwright's built-in HTML reporter writes a self-contained folder with the report for one test run. Nothing in that folder says whether a test is getting worse across runs.

Retries make the gap harder to see. Playwright doesn't retry failing tests by default, and once you turn retries on, Playwright labels a test "flaky" when it failed on the first run and passed on a retry. That label sits in one run's report. On a green build, nobody goes looking for it.

Sharding spreads the problem across machines. Pass --shard=x/y and Playwright splits the suite, so with four shards each one runs a quarter of the tests. Without merging, each test shard has its own test report.

By then the suite needs more than one run can tell you. The fix is one tool per job you have, wired into Playwright Test through a route you can check against your own config.

How we picked

A tool only helps if your Playwright results reach it, and the route they take is the first thing to check against your own setup. On this list, Argos gets results through its own reporter. Zephyr takes JUnit XML through an API, and Happo wraps the test command. Currents' pwc test replaces playwright test. Playwright Workspaces works from a generated playwright.service.config.ts, and TestingBot gives your tests a wsEndpoint to connect to.

Playwright's baseline

Every tool on this list adds to what Playwright Test already does. Playwright Test ships several built-in reporters and supports custom ones, and the --reporter command-line option is the easiest way to try a built-in one. The HTML reporter covers one run, and the JUnit reporter produces a JUnit-style XML report. Retries label flaky tests within one run, and --shard=x/y splits the suite. expect(page).toHaveScreenshot() compares screenshots against reference screenshots that Playwright generates on the first run.

Ask what a tool adds on top of that before you add it.

AI test generation

AI test generation gets no third-party entry. Playwright ships three test agents out of the box: planner, generator and healer. The Playwright MCP server gives LLMs browser automation through the Model Context Protocol, working from structured accessibility snapshots. Start with the built-in agents and MCP before you pay for a generator.

The five questions

We checked each tool against the same five questions:

• Does it keep each Playwright test's results across CI runs, so you can see trends and when a test started failing?
• Does it show Playwright traces, screenshots, videos or step details for a failed test?
• Does it flag tests that pass and fail on the same code, or on retry, and track them over time?
• Does it run Playwright tests in parallel across machines, browsers or a cluster?
• Do its pages say whether it is open source and self-hostable, or hosted only?

We weigh a tool's own reporter above a JUnit upload, because the upload gives the tool only what the XML file holds. A tool that answers none of these questions for your suite doesn't belong in your pipeline yet.

Currents

Currents is our product. Currents ships its own native Playwright reporter. pwc-p is a command-line executable that implements Currents Orchestration for Playwright. Add the Currents reporter to playwright.config.ts by hand and keep running playwright test as usual, or run the pwc executable in place of playwright test.

The tests don't move. With Currents Orchestration, the tests still run in your existing CI environment, and the orchestrator client talks to Currents to get task assignments and report results.

Test history and flaky tests

Test Explorer finds flaky, failing or slow tests and follows how their behavior changes over time. Its % Flaky Trend compares a test's flakiness across two equal time periods, such as the last 30 days against the 30 days before them. Click a test and you get its history of executions, performance metrics and top errors.

Playwright's flaky label says a test flaked in one run. The trend says whether that test flakes more than it did in the previous period, and that is the question that decides what to fix first.

Failure artifacts

A run page's Attachments tab lists every screenshot, video, trace and other file of the run. A trace on the run page's Attachments tab opens in the trace viewer through its Open trace button.

Parallel execution

Currents Orchestration doesn't split tests across CI machines in advance. It keeps a live queue of pending tests and hands each one to a machine as that machine becomes free. Without fullyParallel, Playwright assigns entire test files to shards, so if test files are not evenly sized, certain shards may end up running significantly more tests than others. With a queue, a machine that finishes early takes the next test instead of waiting for the slowest shard.

Who it fits

Currents fits a team running a sharded, retried Playwright suite in CI that has outgrown reading one report per shard per run. Currents answers test history, failure artifacts, flaky test detection and parallel execution in one tool, so it is where that team should start. If your suite runs on one machine and the HTML report answers your questions, Currents adds more than you need yet.

Reporting and test management

A richer report and a test management tool solve different problems. A richer report gives you a better file to read after a run. Test management is a different job: with Xray, you define your test strategy in your Jira board and ingest the execution results into Xray. Playwright's built-in JUnit reporter produces a JUnit-style XML report.

Monocart Reporter

Monocart Reporter is a Node.js reporter for Playwright Test. You install it as an npm dev dependency with npm i -D monocart-reporter. Monocart Reporter builds an interactive report in which tests can be grouped and filtered quickly.

Animated preview of the Monocart Reporter HTML report: a tree grid of Playwright tests with grouping and filtering. Image: Monocart Reporter.

Sharded suites get a merge that keeps the shards apart. When you merge shard reports, Monocart Reporter adds a suite for each shard titled with the machine's hostname, recalculates the summary and copies all attachments to the merged output directory.

Two limits come from its own docs. The trend chart needs historical data, and instead of a server database Monocart Reporter can collect that data from the previous run's report before each test run. In CI, that means keeping the previous report around for the next run. Monocart Reporter's docs say the Trace Viewer requires the trace file to be loaded over http:// or https:// without CORS issues. Serve the report over http rather than opening it from disk.

Monocart Reporter fits teams that want a richer report file than the HTML reporter and no service to run. If carrying report files from one CI run to the next sounds like a chore, pick a hosted tool instead.

Xray

Xray's Playwright workflow generates a JUnit report. You run the tests with Playwright's JUnit reporter, and you send the report to Xray through its API or one of its integrations. Xray added annotations to Playwright's JUnit reporter that set details for each test case in the test code, such as its summary or a link to a Jira requirement or story.

The workflow puts the test strategy first. You define it in Jira with manual, automated or Cucumber tests, run the tests from your CI/CD tool and import the results into Xray. Xray aims to centralize all of a project's information in one place that anyone can access.

Xray fits teams whose test strategy and requirements already live in Jira and who need automated results traced back to stories. If your requirements don't live in Jira, the story links in those annotations have nothing to point at.

Zephyr

Zephyr is SmartBear's Jira-native test management app for planning, creating, executing and tracking testing inside Jira. Zephyr accepts JUnit-format XML test results through an API endpoint, and Zephyr's docs say any framework that can export that file type should work with it.

Zephyr's screen for adding users, inside Jira. Image: Zephyr.

Set the query parameter autoCreateTestCases=true when you upload, and Zephyr creates the test cases that don't already exist.

Know one behavior before you lean on its history: starting a new test execution when you rerun a test cycle archives the previous execution result.

Zephyr fits Jira teams that plan and track manual and automated testing together in test cycles. If your team doesn't plan its testing in Jira, there are no test cycles for the uploaded results to land in.

Cloud and Kubernetes browser grids

With Selenium Grid you don't have to change your code: Playwright connects through the SELENIUM_REMOTE_URL environment variable. When connectOptions is set, Playwright's default browser, context and page fixtures use the remote browser instead of launching a browser locally.

BrowserStack Automate

BrowserStack Automate runs your Playwright tests on an extensive list of browsers and mobile devices.

BrowserStack Automate supports running Playwright tests from CI, and its Playwright docs also list Local Testing.

The device pool is the reason to pick it. The BrowserStack Automate docs for Playwright cite more than 3,500 real desktop, Android and iOS devices and mobile browsers to test on, and the same page calls that pool its Selenium grid.

BrowserStack Automate fits teams that must cover real mobile devices, Android and iOS both, not only desktop browsers, and want to keep triggering the suite from CI. A desktop-only suite doesn't need that range when the browsers on its CI machines already cover its targets.

Azure App Testing

Azure App Testing has a hub in the Azure portal, and you create Playwright Workspaces from that hub. Playwright Workspaces is a fully managed cloud browser platform. Setup generates a playwright.service.config.ts file that points Playwright at Playwright Workspaces and authenticates it. Tests then run in parallel on managed cloud browsers.

The Playwright Workspaces reporter saves test reports to Azure Storage for viewing in the Azure portal, and Playwright Workspaces gives access to execution artifacts, logs, traces, screenshots, recordings and browser session data. After a run completes, the results, trace files and other run files are also on the client machine that ran the tests.

Azure App Testing fits teams that already run on Azure. Both ends of its Playwright setup sit in Azure: the generated service config authenticates to Playwright Workspaces, and the reporter writes to Azure Storage for the Azure portal. Without an existing Azure account, that is a new cloud account to open before the first test runs, so weigh the other grids first.

TestingBot

TestingBot is a cloud grid of real browsers and Android devices that you point an existing Playwright suite at. Set the wsEndpoint to TestingBot's cloud and your tests run in parallel on real browsers and operating systems. TestingBot spreads Playwright workers across many single-use virtual machines running in parallel.

Each session records a full HD video, Playwright logs, the browser console log and a network HAR. TestingBot's AI failure analysis reads a test's logs, status messages and stack traces and classifies the failure as an application bug, a test-script problem, an environment issue or a flaky test.

Every Playwright test shows up in the TestingBot dashboard, as an unnamed test by default. Plan for that before the dashboard fills up.

TestingBot fits teams that want per-session evidence and a first read on a failure's cause from the grid itself. If the desktop browsers on your CI machines already cover your targets, a grid adds setup for little gain.

Moon

Moon is a browser automation solution that works with Selenium, Cypress, Playwright and Puppeteer and launches browsers in Kubernetes or OpenShift. Playwright tests connect to a Moon WebSocket endpoint URL, and otherwise the test code is the same as a standard Playwright example.

Moon runs as many browsers at once as the cluster's capacity allows, on any hardware or in the cloud. The Moon docs recommend installing it with a Helm chart, so you deploy and run it yourself.

Moon fits platform teams that already run a cluster and want browsers inside their own infrastructure. A team with nobody to run a Kubernetes cluster should pick a hosted grid.

Anti-pattern

A grid to fix slow CI

The pipeline is slow, so the suite gets pointed at a cloud grid and everyone waits for CI time to drop. A grid supplies remote browsers. With connectOptions set, the default browser, context and page fixtures use a remote browser instead of launching one locally.

Fix

Fix the split and the reading first: balance the suite across CI machines, and send results somewhere you can compare them across runs. Add a grid when the browsers or devices you need aren't on your CI machines.

Visual regression testing

Screenshot assertions are cheap to write and slow to review. Playwright Test compares screenshots with expect(page).toHaveScreenshot() and generates reference screenshots on the first run. Playwright's HTML reporter produces a self-contained folder with the report for one test run, which can be served as a web page. Someone asked for a CLI tool to interactively review and update snapshot test results (#14883). A maintainer replied that there is no such tool yet and that failed screenshots can be gone over manually in the HTML report. The request was closed as not planned.

Argos

Argos describes itself as open-source visual regression testing for Playwright, Storybook and Vitest. The Argos reporter uploads screenshots and traces to Argos as your tests run. Failure screenshots and traces go up with the build, so you open them in Argos instead of downloading CI artifacts, whether the test failed for good or passed on retry.

Argos marks unstable tests with a flaky badge, and each test has its own page with its history and stability scores. That page shows the builds where the test first and last changed, over any period.

Argos fits teams that want open-source visual review, failure traces and per-test flaky history from the same reporter.

Happo

Happo is a hosted visual regression testing service with support for multiple browsers and accessibility testing. The happo/playwright module integrates a Playwright suite with Happo, and you enable Happo by wrapping your test command with the happo script.

Happo report compare page showing visual diffs to accept or reject. Image: Happo.

On a run, the happo CLI builds your test suite and uploads it, Happo renders every snapshot on its own infrastructure, and the resulting report is compared against a baseline. Happo screenshots Playwright tests in Chrome, Firefox, Safari and Edge, and in Safari on iPhone and iPad, in parallel. When a change adds an accessibility violation, Happo blocks approval and marks the element that broke the rule on a screenshot, right next to the visual diffs.

For a suite spread across machines, Happo can produce one combined report for all the test runs. To combine them, you tie the individual runs together with the --nonce CLI argument and call npx happo finalize after the whole test suite is done.

Happo fits teams that want accessibility violations caught in the same review as visual diffs. Teams that can't send their suite to a hosted service should pick a tool they can run themselves.

Percy

Percy is a visual testing platform that captures screenshots during test runs and compares them against a baseline. You add Percy to existing tests by installing its SDK for Playwright. Then you put the project token in an environment variable, locally or in CI, so Percy can receive screenshots while the tests run.

Percy renders the screenshots it captures on more than 3,500 real browsers and devices rather than emulators. Percy shows differences in side-by-side views, as overlays and with visual markers. The Percy dashboard lists projects, recent builds and visual changes tied to code updates, and the dashboard is a central place for tracking visual history.

Percy fits teams that need visual checks rendered on real devices. Percy states that it is not an open source visual regression testing tool. If your team's policy requires open-source tooling, that statement rules Percy out.

At a glance

Check the route column against your config before anything else: a tool whose route doesn't fit your pipeline won't help, however good the rest of it is.

The Best for column is our call; the route column comes from each tool's own docs.

How to choose

Start with Currents if you run a sharded, retried Playwright suite in CI. Currents' Test Explorer shows how a test's flakiness has changed between two equal time periods. Currents Test Orchestrator balances the load using historical execution data.

For the other jobs, pick by the condition you have:

• If you want an interactive report with grouping and fast filtering, choose Monocart Reporter, which can collect trend history from the previous run's report instead of a server database.
• If you need automated results traced back to Jira requirements and stories, choose Xray.
• If you plan, execute and track testing directly within Jira, choose Zephyr, SmartBear's native test management solution for Jira.
• If you need mobile devices, choose BrowserStack Automate, whose Playwright docs say it runs Playwright tests on an extensive list of browsers and mobile devices.
• If you want a full HD video and a network HAR with every Playwright session, choose TestingBot, whose AI failure analysis can classify a failed test as an application bug, a test-script problem, an environment issue or a flaky test.
• If your infrastructure already runs on Azure, choose Azure App Testing.
• If a platform team already runs a Kubernetes cluster, choose Moon.
• If you want open-source visual review, choose Argos.
• If accessibility violations should block approval, choose Happo.
• If visual checks must render on real devices, choose Percy.

Skip grids if the browsers on your CI machines already cover your targets.

Anti-pattern

One tool from every category

A suite gets a new reporter, a Jira upload, a grid endpoint and a visual service in the same quarter. Each one adds a reporter entry, an upload step or an endpoint to keep working, and when a run breaks, the first job is working out which layer broke it.

Fix

Add a tool only when a symptom you already have calls for it: flaky tests you can't follow across runs, shards that finish far apart, screenshot failures nobody reviews.

When to add nothing

A small suite where retries and the per-run HTML report already tell you what broke doesn't need any of these tools yet. Come back to this list when the report stops answering the question you're asking.

Frequently asked questions

What are the best Playwright tools?

Start with Currents if you run a sharded, retried Playwright suite in CI. Currents' Test Explorer shows how a test's flakiness has changed between two equal time periods, and Currents Test Orchestrator balances the load using historical execution data.

Does Playwright track flaky tests across runs?

Retries label flaky tests within one run. With retries enabled, Playwright labels a test flaky when it failed on the first run and passed on a retry. Playwright's built-in HTML reporter writes a self-contained folder with the report for one test run, as Playwright's baseline covers.

Which test management tools work with Playwright?

With Xray, you run the tests with Playwright's JUnit reporter and send the report to Xray through its API or one of its integrations. Zephyr accepts JUnit-format XML test results through an API endpoint, and Zephyr's docs say any framework that can export that file type should work with it. Playwright's built-in JUnit reporter produces a JUnit-style XML report, as Reporting and test management explains.

What is a good reporting tool for Playwright besides the HTML reporter?

Monocart Reporter is a Node.js reporter for Playwright Test. Monocart Reporter builds an interactive report in which tests can be grouped and filtered quickly. Monocart Reporter fits teams that want a richer report file than the HTML reporter and no service to run, as the Monocart Reporter entry explains.

Do I need a third-party AI test generation tool for Playwright?

Start with the built-in agents and MCP before you pay for a generator. Playwright ships three test agents out of the box: planner, generator and healer. The Playwright MCP server gives LLMs browser automation through the Model Context Protocol, as AI test generation covers.

Which visual regression testing tool works best with Playwright?

Choose Argos if you want open-source visual review, Happo if accessibility violations should block approval, and Percy if visual checks must render on real devices. Each condition and its pick are listed in How to choose.

Which cloud browser grid should I use with Playwright?

Choose BrowserStack Automate if you need mobile devices, Azure App Testing if your infrastructure already runs on Azure, and Moon if a platform team already runs a Kubernetes cluster. If you want a full HD video and a network HAR with every Playwright session, choose TestingBot. Skip grids if the browsers on your CI machines already cover your targets, as How to choose says.

Is there a CLI to review and update Playwright screenshot diffs?

Playwright updates reference screenshots with the --update-snapshots flag. For review, someone asked for a CLI tool to interactively review and update snapshot test results, and a maintainer replied that there is no such tool yet and that failed screenshots can be gone over manually in the HTML report. The request was closed as not planned, as Visual regression testing notes.