With test impact analysis (TIA), you can ask mabl, from your AI coding agent, which of your existing tests a code change affects. TIA finds those tests, runs the ones that are safe to run, and hands back a report that you can attach to a pull request. If it finds no coverage, it says so and offers to hand off to the test authoring skill.
This article walks through the full test impact analysis workflow.
Before you start
- Install mabl skills in your AI coding agent, such as Claude Code, Cursor, or GitHub Copilot. TIA is part of the mabl skills plugin, which also connects your agent to the mabl MCP.
- Install the mabl CLI and log in if you want TIA to run test locally.
- Work in a repo that maps to a mabl application. The analysis is scoped to one application in mabl. If your repo spans more than one application, TIA runs one analysis per application and combines the results.
Start the analysis
After your unit tests pass and before you open a pull request, ask your coding agent about the mabl tests your change affects. You don't need to describe the change. TIA reads your code changes and describes them itself, in the same product terms your tests use.
To start running affected tests that are read-only or self-cleaning, prompt your agent with something like:
Validate my change against mabl.
If you only want the list of affected tests, ask something like:
What mabl tests are impacted by my change?
Before TIA analyzes anything, it identifies the scope, including the workspace, application, environment, URL, credentials, and whether tests run locally or in the cloud. If more than one mabl application could match your code, TIA asks rather than guesses. To validate changes that aren't deployed yet, ask TIA to run locally against your dev server, or point it at a preview deployment.
How does TIA choose tests?
To learn more about how TIA finds tests related to your code changes, see how test impact analysis works.
Review the execution plan
TIA presents the tests it found as an execution plan before anything runs. Tests fall into three groups:
- Running now - tests that only read data, or clean up after themselves. TIA runs these without asking, one first as a canary.
- Needs your approval - tests that write shared data, whose cleanup TIA can't verify, or require a billable feature to run locally. TIA lists what each one writes and where, and waits for you to approve them.
- Not running - tests that are disabled, unreliable, or outside the scope you set. Each one comes with its reason, so a skipped test is never mistaken for a forgotten one.
Every test links back to mabl so you can open it.
TIA never executes mabl plans on its own. If an existing mabl plan covers most of the affected tests, TIA points that out and lets you decide whether you want to run it.
Review the report
When the runs finish, TIA writes a short report with five blocks:
| Block | What it tells you |
|---|---|
| Scope | The application, workspace, environment, and build the tests ran against, and the commit the report is for. This information helps you confirm that tests ran against a build that includes your change, not just that they passed. |
| Analysis | How many tests the analysis returned, how many coverage gaps it found, and whether more tests may exist beyond the result limit. |
| Validated | Each test that ran, with its result. Failures are sorted by cause, so a test that was already failing before your change is not reported as your regression. |
| Not run | Each test that didn't run and why: disabled, pending your approval, out of scope, or too unreliable. |
| Gaps | Each user-facing area your change reaches with no apparent test coverage, and what happened to it: a test was created, or the gap was deferred. |
Investigate failures
If a test failed because of your change, ask your agent to dig in. It can pull the failure evidence and, with the mabl debugging skill installed, reproduce the failure in a real browser against your fix. See debug mabl tests from your AI coding agent.
Re-validate a follow-up commit
If you push a follow-up commit, ask again. TIA re-analyzes the new commit, because a later push can reach surfaces that the first analysis never saw. The new report lists results carried over from the earlier commit separately from results for the current one, so you can see which tests were checked against which commit.
Create tests for gaps
For every coverage gap in the report, TIA offers to hand off to the test authoring skill. Accepting the offer starts the authoring workflow: the authoring skill plans a test for the gap with you, then builds it in the cloud or locally. Authoring is always opt-in. Either way, TIA calls out the gap in the report so it isn't forgotten.
If you've just added a new screen or control, you can also ask TIA directly whether anything covers it.
Save your project defaults
The first time you run TIA, it has to work out which application maps to your repo, which environment and credentials to use, and how your team labels its critical tests. Those answers rarely change. To skip those questions next time, ask TIA to save them to the instruction file your agent already reads, such as CLAUDE.md or AGENTS.md. TIA uses those notes as its starting point, but they never remove a safety check: tests that write shared data still wait for your approval, and TIA still won't start a plan run on its own.