How do you structure a monorepo or multi-repo for tests across many teams?
60-second answer
It depends on how the product code is organised. My preference is to keep tests close to the code they test: unit, component and API tests live in each service's repository so they change together and run in that service's pipeline. Cross-service end-to-end and contract tests can live in a shared repo or the monorepo's e2e package. Shared utilities, like auth helpers, test data builders and reporting, go into an internal library with versioning. I define ownership with CODEOWNERS and a common style so teams can contribute safely.
Explanation
| Tests with code | Central test repo | |
|---|---|---|
| Ownership | Service team | QA/platform team |
| Change coupling | Same PR as code | Separate PRs, drift risk |
| Pipeline | Per service | Separate, often slower |
| Reuse | Via shared library | Natural |
In monorepos (Nx, Turborepo, Bazel), use affected-project detection to run only relevant tests.
Example
Moving API tests into each service repo cut "test broke because code changed" tickets by 70%, since developers updated tests in the same pull request.
Sample code
# .github/CODEOWNERS
/e2e/ @acme/qa-platform
/packages/test-utils/ @acme/qa-platform
/services/orders/tests/ @acme/orders-team
/services/payments/tests/ @acme/payments-team @acme/qa-platform