Test impact analysis
Test impact analysis is selecting the tests a code change can affect, using a recorded map from source code to the tests that exercise it. The map names the tests covering the files a commit touched, and only those run. The rest of the suite is skipped for that change, which shortens feedback.
The longer version
The map is built by observation or by static analysis. In the observed form, a coverage tool records which source files each test executes during a run and stores the result. When a developer changes three files, the selector looks them up and returns the tests whose recorded coverage includes any of them. The static form reads imports and call graphs instead, which is cheaper to build and finds more false links. Either way the output is a shortlist, produced in seconds, from a suite that might take hours in full.
It differs from test case prioritization, which keeps the whole suite and changes the order so likely failures come first. Impact analysis changes the contents of the run: tests outside the shortlist do not execute at all. The two combine naturally, with the shortlist run in priority order. It differs again from running the tests nearest the change by folder or by naming convention, which is a guess; the map is a record, and it knows that a change to a shared date helper touches the invoicing tests three directories away.
The map fails by going stale. A test added last week has no recorded coverage until someone runs it, so changes it would catch select nothing. Dynamic behaviour breaks it too: configuration read at runtime, reflection, generated code and data-driven dispatch execute code the map never linked to the change. A selector that quietly returns an empty list passes the build, and the miss is found in production.
Teams therefore keep a safety net. Impact-selected runs gate the pull request, while the complete suite still runs on a schedule or before release, and a failure there that the shortlist missed is treated as a defect in the map. The method pays off on large suites where a full run is too slow to wait for, and adds little on a suite that finishes in a few minutes.
Common questions
What is the difference between test impact analysis and test case prioritization?
Test impact analysis decides which tests run for a change and skips the others. Test case prioritization keeps every test and decides the order, so the ones most likely to fail run first. Used together, the impact-selected tests run in priority order and the full suite follows on a schedule.
How does test impact analysis know which tests a change affects?
From a map built during earlier runs, where a coverage tool records which source files each test executed, or from static analysis of imports and call graphs. A changed file is looked up in the map, and every test whose recorded coverage includes it is selected.
Is test impact analysis safe to rely on alone?
Not as the only gate. A stale map, a newly added test, runtime configuration and generated code all hide real dependencies, and the selector returns nothing for them. Keep a scheduled full run, and read any failure it finds that the shortlist missed as a gap in the map.
When is test impact analysis worth setting up?
When a full run takes long enough that developers stop waiting for it, so feedback arrives after the context is lost. A suite that finishes in minutes gains little, because building and maintaining the map costs more than the time saved.
Does test impact analysis work for end-to-end tests?
Partly. An end-to-end test touches so much code that nearly every change maps to it, so the shortlist barely shrinks. The method works best on unit and integration tests with narrow coverage, while the end-to-end layer is kept small and chosen by risk.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.