Coding agents have accelerated the pace of development, but one question has remained the same: "Are my changes safe to ship?" Running every test on every change is slow and wasteful. With test impact analysis (TIA), mabl finds the existing tests your code change affects, so you can run the ones that matter and see where coverage is missing. Start from your AI coding agent while you work, then add TIA to your CI pipeline to check every pull request.
With test impact analysis, you can:
- Find relevant tests. mabl searches your tests for the ones your change reaches and tells you why each one is relevant.
- Run tests before opening a PR. Get an interactive execution plan and run affected tests directly inside your workflow.
- Identify regressions. See pass/fail results sorted by root cause.
- Make relevant edits. Add necessary updates to existing tests by handing off to the authoring agent or direct edit.
- Add coverage for untested areas. TIA lists the affected areas that lack coverage, and you can hand them off to test authoring.
Try it from your coding agent
Running TIA from your coding agent is the easiest way to see what it finds for your own changes. Test impact analysis ships with mabl skills for Claude Code, Cursor, GitHub Copilot, and OpenAI Codex.
- Install mabl skills in your coding agent, following the installation instructions in the repo.
- If running tests locally, authenticate the mabl CLI once with
mabl auth login --auto. TIA uses the CLI to run tests against your locally running app, but no CLI is needed to run tests in the cloud. - After your unit tests pass, ask your coding agent about the mabl tests your change affects.
- 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?"
The skill then identifies the correct workspace, application, and environment. If the app is ambiguous, TIA will confirm with you first before presenting the tests it found as an execution plan: what runs now, what needs your approval, and what won't run and why. When you ask it to validate, it runs the safe tests and hands back a summary report ready to attach to your pull request.
Add TIA to your CI pipeline
Once you are confident with the results from your coding agent, add TIA to your CI pipeline to run automatically on pull requests. Use the mabl CLI command mabl tests impact with a description of your change, such as the PR's title and description, to identify the impacted tests and coverage gaps, similar to the output from the TIA mabl skill in your coding agent. Pass the --output markdown flag to generate a summary report you can post directly as a pull request comment.
By default, the analysis is advisory: it identifies the tests your change touches without executing them, and it won't fail the CI job based on its findings. Depending on your workflow, you can also configure the job to execute the impacted tests by passing their IDs to mabl deployments create --test-ids. Include the --await-completion option if you want the CI job to wait for the mabl test runs to finish and fail if any test fails.
For full syntax and parameter options, see mabl tests impact and mabl deployments create in the CLI command reference.
Get more from TIA with a knowledge graph
Early access
Knowledge graphs are available in early access, and pricing and packaging are subject to change. We will be rolling them out to customers over the coming months. If you'd like access sooner, reach out to your customer success manager.
Test impact analysis works by searching your tests. A custom knowledge graph of your application gives it much more to work with. The graph maps your application's pages, workflows, and features, and records which tests cover each one and which steps do the covering. With a graph, TIA can rank the tests it finds by how your change reaches them and point to the part of your application that connects each test to the change.