Selection strategy

Test selection vs path filters, Nx and Turborepo

Published and last updated September 25, 2026 · By Aditya Kale, primary maintainer

These approaches overlap, but they do not answer exactly the same question. The best baseline is often the simplest one that is safe, maintainable, and measurably cheaper for the repository.

What each approach knows

Approach	Primary evidence	Strength	Main boundary
Changed-path rule	Files and directories in the Git diff	Cheap, explicit, easy to review	Shared and transitive dependencies must be maintained manually
Nx/Turborepo-style affected task graph	Declared projects, packages and task dependencies	Fits repositories already organized around that graph	Precision stops at the configured project or task boundary
Source dependency test selection	Resolved imports from changed source to tests	Can narrow within a package and retain per-test provenance	Dynamic behavior, unsupported languages and resolution gaps require fallback
DiffCI observation	Git delta, dependency evidence, CI structure and execution comparison	Measures whether a selection would be safe and worthwhile before CI authority changes	Advisory; it does not replace or accelerate required production CI

Precision is not the same as value

A dependency graph can select fewer tests than a directory rule and still cost more after analysis overhead. A package-level task graph can be less precise but cheaper, easier to explain, and already integrated with build caching. The economic comparison needs actual command execution.

DiffCI's open benchmark found repositories where a simple path rule was already optimal, repositories where dependency analysis found a narrower candidate, and repositories where mandatory fallbacks dominated. That mixture is why DiffCI reports the baseline rather than declaring one method universally better.

Compare the command and maintenance surface

The approaches differ in where their truth is maintained. A path rule is written by hand, a task graph follows declared project relationships, and a source graph derives reachability from code. The commands can look equally small while carrying very different maintenance obligations:

# GitHub Actions path boundary
on:
  pull_request:
    paths: ["packages/billing/**", "packages/shared/**"]

# Nx project/task graph
npx nx affected -t test --base=origin/main --head=HEAD

# Turborepo package/task graph
turbo run test --filter="...[origin/main]"

# DiffCI observation and measured comparison
npx "@diffci.com/diffci@latest" check

Question	Path filters	Nx/Turborepo	Source dependency selection
Who maintains dependency truth?	Repository authors maintain glob-to-job mappings	Project and task graph configuration	Resolver plus explicit fallback and always-run policy
Typical selection unit	Workflow or command	Project or task	Test file, package, or full fallback
Analysis overhead	Very low	Graph calculation and cache lookup	Git, repository, source, and test-graph analysis
Critical failure mode	Stale or incomplete glob	Missing task/project dependency	Unsupported or unresolved source edge
Required safety response	Broaden rule or run all	Repair graph or run broader task	Record boundary and run full command

How to choose

Use path filters first when repository boundaries are stable, shared dependencies are limited, and the mapping is easy to review.
Use the monorepo task graph when Nx, Turborepo, or an equivalent already defines the authoritative project and task relationships.
Evaluate source dependency selection when large packages contain many independently reachable tests and coarse project selection still runs too much.
Keep full-run triggers regardless. Lockfiles, workflows, root configuration, and incomplete evidence can invalidate every narrow strategy.

Run the comparison without changing CI

npx "@diffci.com/diffci@latest" check

The local check analyzes the change and runs inferred full and selected commands when possible. It retains fallback reasons and measured timings. Use observe --no-send when analysis should not execute tests.

For GitHub Actions prerequisites, see the test impact analysis guide. For a safety checklist, see how to run affected tests safely.