The question of whether to keep tests in the same repository as application code or in a dedicated test repository does not have a single correct answer. The right structure depends on your team’s deployment cadence, ownership model, and test type mix. Monorepos with collocated tests work well when tests and the code they cover change together frequently. Separate test repos work well when QA operates as an independent function, when test coverage spans multiple application repos, or when audit and change-history separation is a requirement. Each structure fails in predictable ways as teams grow past the assumptions it was built on.

The Case for Keeping Tests in the Application Repository

Collocating tests with application code is the dominant pattern in product engineering teams that practice continuous integration. When tests live in the same repository, a developer making a code change can update the relevant test in the same commit. The CI pipeline runs the tests as part of the same build, and a broken test immediately blocks the PR. This tight coupling between code and tests is the main argument for colocation: it prevents tests from drifting out of sync with the code they validate.

Monorepos with collocated tests also simplify dependency management. When the test file and the module it tests share the same package.json or requirements.txt, there are no cross-repo versioning issues. A developer upgrading a library can immediately see whether the tests still pass against the updated version without needing to coordinate with a separate test repository maintainer. This matters most for unit and component tests, where the coupling between implementation and test is tightest.

Framework reuse across services is another practical benefit. In a monorepo containing multiple services, shared test fixtures, helper functions, and custom assertions can live in a common package that all service test suites import. Teams using Playwright or Pytest can maintain a single test utilities package versioned alongside the services, avoiding the duplication that occurs when each service has its own copy of common infrastructure. For teams managing this type of setup, Astaqc’s test automation services help design shared frameworks that scale across services without creating brittle shared state.

The Case for a Dedicated Test Repository

A separate test repository makes sense when the testing function operates independently from the development team, when tests span multiple application repositories without a natural home in any of them, or when the audit and compliance requirements for a project demand separate change histories for application code and test assets.

QA teams that maintain test suites across multiple independently deployed services often find that a separate test repo gives them cleaner ownership. The QA team controls the branching strategy, release cadence, and dependency management of the test codebase without needing merge permissions in every application repo. This is common in organizations where QA is a separate department, in regulated industries where test evidence must be independently maintained, and in teams that provide manual testing alongside automated suites where human test cases and automation live together.

A dedicated test repo also works well for end-to-end and integration tests that by nature span multiple services. An E2E test suite that validates a checkout flow involving a cart service, a payments service, and an email notifications service has no single application repo where it naturally belongs. A dedicated E2E test repo avoids the awkwardness of placing cross-service tests in one service’s repo, where they appear disconnected from the code they actually exercise.

External contractors or QA vendors providing QA team services often operate more effectively with a dedicated test repository, since they can be granted access to the test codebase without receiving read access to production application code. This matters for organizations with IP protection requirements or those using external QA partners for regulated software categories.

When Each Structure Works and When It Breaks Down

The table below summarizes where each approach performs well and where it introduces friction as the team scales:

Hybrid Structures That Work in Practice

Most mature engineering organizations end up with a hybrid: unit and integration tests collocated in each service’s repository, and a dedicated E2E test repository for cross-service user journey tests. This split matches test type to ownership model. Unit tests belong to the developer who writes the code. E2E tests that validate user flows across multiple services belong to the QA function or the platform team, and a separate repo gives them the independence to manage those tests without needing write access to every service repo.

The key to making a hybrid work is defining the boundary clearly. A common mistake is letting E2E tests grow inside service repos because it feels convenient, then finding three years later that the service with the most traffic has become the de facto owner of E2E infrastructure that everyone depends on. Moving those tests to a dedicated repo after the fact is painful. Starting with the boundary in the right place avoids that refactor.

Another effective hybrid is keeping the test framework as a published internal package that multiple repos consume, while each repo owns its own test files. The shared package contains custom assertions, authentication helpers, API clients, and reporting utilities. Each service’s test suite pins to a version of the shared package, meaning framework updates are explicit opt-ins rather than automatic. This avoids the situation where a framework change in one service’s directory breaks another service’s tests silently. For teams designing this type of shared infrastructure, the manual testing vs. automated testing guide and the complete software testing guide provide useful context on where different test types sit in the overall strategy.

Teams deciding on this structure as part of a broader quality initiative will find that the repo structure choice follows from the ownership model rather than leading it. The question to answer first is not where the test files should live but who owns each category of test and what that team needs to move fast without creating blockers. For help designing a testing strategy or building out a testing documentation practice alongside the structure decision, Astaqc’s team can provide support across the planning and execution phases.

Frequently Asked Questions

Should unit tests always live in the application repo?

Yes, in almost every case. Unit tests are tightly coupled to the implementation they test, and collocating them in the application repo ensures they run in the same CI pipeline, change in the same commit, and are visible to the developer making the code change. Moving unit tests to a separate repo adds coordination overhead with no meaningful benefit.

What is the most common reason separate test repos fail?

Drift. When developers update API contracts, change response schemas, or remove endpoints without notifying the QA team, the tests in the separate repo keep expecting old behavior. The tests fail in CI against a staging environment but may pass against the previous version, masking the inconsistency. The fix is explicit API versioning contracts or automated notification when application code changes touch tested surfaces.

How do you handle shared test utilities across a separate test repo and application repos?

Publish shared utilities as an internal package — an npm package in a private registry, a PyPI package in a private feed, or a Go module in an internal proxy. Each consuming repo pins to a version of the shared package and upgrades explicitly. This prevents a shared utility change from silently breaking test suites that depend on it across multiple repos.

Does having tests in a separate repo slow down CI?

It can, if the CI pipeline for E2E tests needs to wait for the application to be deployed before tests can run. Cross-repo CI workflows require explicit triggering — a deployment pipeline dispatching a test run in the test repo, or a shared webhook. When this is set up correctly, E2E tests run automatically on every deployment without developer intervention. When it is not set up correctly, tests run manually and provide no deployment gate.

Is there a best practice for test repo naming and branching?

A test repo’s main branch should track the application’s main branch semantically, even if the commit histories diverge. Branch naming conventions like feature/APP-1234-login-flow help QA and developers trace which feature branch a test was written against. If your application uses release branches, consider whether the test repo mirrors them — this matters for teams that release a previous version and need to run the corresponding test suite against it. The AI in software testing guide covers how automated tooling is changing how teams manage test codebases in 2026.