Monorepo Test Aggregation: Unify Playwright, Jest & pytest Results (2026)
In a monorepo, frameworks emit results in different formats. Test aggregation combines them into one view per run — overall health, flakiness, ownership.
In a monorepo, several test runners (Playwright, Jest, pytest, JUnit) produce results in different formats and separate reports. Test aggregation collects them into one view per run — unified by commit — so you see overall health, flakiness, and ownership across packages instead of stitching together a dozen disconnected reports.
Key takeaways
- A monorepo runs many frameworks; each emits results in its own format and its own report.
- Aggregation unifies those results per run/commit into a single source of truth.
- Without it, there's no overall pass rate, no cross-package flakiness view, and unclear test ownership.
- Aggregation pairs with selection — run the affected packages, then combine their results.
- A CLI that auto-detects frameworks removes the per-framework adapter work.
Monorepos make sharing code easy and testing hard. A single commit can touch a library that a dozen packages depend on, those packages run different test frameworks, and each framework drops its own report somewhere. The result is no single answer to a simple question: did this run pass, and if not, what’s the one thing to fix? Test aggregation is how you get that answer back. Where we reference Qualflare, we describe only what it actually does.
The problem: many runners, many reports
In a monorepo, a frontend package might run Playwright and Jest, a Python service runs pytest, and a Java module runs JUnit — all in the same CI run. Each emits results in its own format (JSON or JUnit XML) and its own local report. Stitched together by hand, that’s a dozen browser tabs and no shared truth. There’s no real overall pass rate, no way to see that the same flaky failure is hitting three packages, and no clear owner when a shared-library change goes red across the repo.
What monorepo test aggregation means
Monorepo test aggregation is combining those many runners’ results into one unified view per run, keyed by commit. Instead of separate reports, you get a single picture of the run: overall health, every failure, flakiness across packages, and which package each result belongs to. One commit that breaks five packages reads as one event with a shared cause — not five disconnected red reports.
Why per-framework reports fall short
A framework’s built-in report answers one package’s question for one run, locally. It can’t:
- give you a repo-wide pass rate for the commit,
- spot a flaky test pattern that spans packages,
- cluster failures from different packages to one shared root cause, or
- keep the history across runs that flakiness and trend analysis depend on.
Those are all cross-package, cross-run questions — exactly what a single report can’t answer and aggregation can. And because flakiness is pervasive at scale — Google found that ~16% of its tests have some level of flakiness and identifies it as one of the central challenges of automated testing — seeing it across the whole repo rather than per package matters.
How aggregation works
The mechanics are simple by design: each runner writes its standard results file, and you upload each one to a platform that detects the format and merges them into a single run. Qualflare’s CLI auto-detects 23+ frameworks from the result files themselves — Playwright, Jest, pytest, JUnit, Cypress, and more — so there are no per-framework adapters to write or maintain. It attaches your Git branch and commit to every result, which is what ties the separate runners into one run.
Aggregation and selection go together
The two core monorepo testing problems are complements. Smart test selection decides which packages to run for a change so you don’t test the whole repo every time; aggregation combines the results of whatever ran into one view. Selection keeps the CI feedback loop fast; aggregation keeps it legible. You want both — together they’re core moves when you speed up a slow CI suite, and the unified pass rate they produce is what you track to move DORA metrics like change failure rate and lead time.
Start free with Qualflare — upload results from every framework in your monorepo and see one unified, historical view of each run.
Frequently asked questions
What is monorepo test aggregation?
Monorepo test aggregation is combining the results of multiple test runners — which in a monorepo often span several languages and frameworks — into one unified view per run. Instead of a separate report for Playwright, Jest, pytest, and JUnit, you get a single picture of the run’s health, flakiness, and failures, tied to the commit that produced them.
Why is testing harder in a monorepo?
Because one commit can affect code shared across many packages, several runners produce results in different formats, and it gets unclear who owns a failing test. The two core problems are selection (running only the affected packages) and aggregation (unifying the many runners’ results into one report).
How do you combine results from different test frameworks?
Have each runner write its standard results file — JUnit XML or the framework’s JSON reporter — then upload each one to a platform that detects the format and merges them into a single run keyed by commit. A CLI that auto-detects 23+ frameworks removes the need to write custom adapters per framework.
What does aggregation give you that per-framework reports don’t?
A real overall pass rate for the run, a cross-package view of flakiness and failure clusters, and clear ownership — so a shared-library change that breaks five packages reads as one event, not five disconnected red reports.
