Test impact analysis
Test impact analysis identifies the subset of tests relevant to a code change — by analysing the dependency graph between source files and test files — so CI runs only the affected tests instead of the entire suite. TIA can cut CI time by 5-20x for large monorepos with disciplined dependency tracking.
TIA's mechanics: build a graph of which source files each test exercises (via coverage data, static analysis, or runtime tracing), and for each PR identify the union of tests that touch the changed files. The benefit scales with suite size: a 10-minute suite barely benefits; a 60-minute suite cut to 8 minutes per PR is transformative. The challenges: maintaining the dependency graph (it goes stale as code moves), handling indirect dependencies (a test that loads a config file shouldn't be missed when the config changes), and managing the fallback (run the full suite periodically to catch what TIA missed). Tools include Microsoft's TIA, Google's Bazel-based selection, and language-specific tools like nx.
Discussed in our use-cases
ICP-targeted pages where test impact analysis is part of the framing.
Related terms
- Test pyramid
The test pyramid is the testing-strategy heuristic that recommends many fast unit tests at the base, fewer integration tests in the middle, and very few slow end-to-end tests at the top.
- CI/CD pipeline
A CI/CD pipeline is the automated chain of build / test / deploy steps that runs on every code change.
- Flaky test
A flaky test is one that sometimes passes and sometimes fails without any code change — typically caused by timing dependencies, shared state, network/external-system reliance, or race conditions.