You just changed one utility function. CI kicks off. 2,000 Playwright tests start running.
45 minutes later, you get your green light.
This is the state of E2E testing at scale: every PR pays the price of the full suite, regardless of what actually changed. It's not a tooling problem — it's an information problem. Your CI doesn't know which tests depend on your change. So it runs everything.
ast-impact-mapper-mcp fixes that.
🧠 The Idea: Import Graphs Don't Lie
Every TypeScript project is a directed graph of imports. When you change src/utils/auth.ts, the only tests that need to run are the ones that — directly or transitively — import it.
This isn't guesswork based on filenames or folder structure. It's a precise traversal of your actual dependency graph.
The tool uses ts-morph to parse your TypeScript project (including tsconfig.json, path aliases, JS/JSX files) and builds two graphs:
- Forward graph: file → files it imports
- Reverse graph: file → files that import it
Given a set of changed files, a BFS through the reverse graph finds every test that transitively depends on them. Everything else is safe to skip.
🛠️ Eight Tools for Complete Impact Analysis
Once connected to your AI assistant (Claude, Cursor), the MCP server exposes eight tools:
get_affected_tests
The core tool. Give it a list of changed files — or the raw output of git diff --name-only — and get back every test file that transitively imports them.
Supports TypeScript, JavaScript, and JSX. Matches *.spec.ts, *.test.ts, and files inside __tests__/ directories.
get_affected_tests_by_branch
Same as above, but the server runs git diff itself. Point it at a base branch (default: main) and it handles everything — no manual file listing needed.
get_dependency_graph
Direct imports and importers for any file. Returns JSON by default, or a Mermaid flowchart you can paste straight into GitHub markdown:
graph TD
"src/fixtures/base-fixture.ts" --> "src/pages/google-home-page.ts"
"src/fixtures/base-fixture.ts" --> "src/pages/google-results-page.ts"
"tests/google-pom.spec.ts" --> "src/fixtures/base-fixture.ts"
explain_impact
Finds the shortest import chain from a test file to a changed source file. The AI can say exactly why a test is affected:
"checkout.spec.ts is affected because it imports CartPage.ts → PriceCalc.ts → the file you changed."
get_coverage_gaps
Finds source files that are not reachable from any test through the import graph — completely untested code, found statically in milliseconds, no coverage run needed.
get_test_summary
Project-wide health overview in one call: coverage rate, the 10 most-imported source files (highest blast radius if changed), and tests with the deepest import chains.
refresh_project
Clears the cached AST and dependency graphs for a project root. Call it after switching branches or pulling changes.
get_dependency_graph with format: "mermaid"
A visual flowchart of any file's import neighborhood — ready for GitHub, Notion, or any Mermaid renderer.
🕵️♂️ Real-World Scenario: The Targeted Refactor
You're refactoring DateHelper.ts. You want to run only the affected tests locally before pushing — not the full suite.
You ask your AI:
"I'm about to change
src/utils/DateHelper.ts. Which tests should I run?"
The AI calls get_affected_tests:
"4 tests are affected:
calendar.spec.ts,booking.spec.ts,history.spec.ts, andprofile.spec.ts. Everything else is safe to skip."
You run those 4 tests in 2 minutes. CI confirms green 40 minutes later. That's the 20x feedback loop improvement — not from running tests faster, but from running fewer of them.
🔍 Real-World Scenario: The Unknown Risk
You're reviewing a PR that touches src/api/client.ts. You want to know the blast radius before merging.
You ask:
"How many tests depend on
src/api/client.ts? Show me the dependency graph."
The AI calls get_test_summary, then get_dependency_graph:
"
api/client.tsis imported by 11 other files and is the most-imported source file in the project. Changing it affects 23 test files — roughly 40% of your suite. I'd recommend reviewing this PR carefully."
That's information you couldn't get from a code diff alone.
📊 Example Output
Given this project structure:
src/
fixtures/base-fixture.ts ← imports home-page and results-page
pages/google-home-page.ts
pages/google-results-page.ts
tests/
google-pom.spec.ts ← imports base-fixture
get_affected_tests after changing google-home-page.ts:
{
"changed_files": ["/my-project/src/pages/google-home-page.ts"],
"affected_tests": ["/my-project/tests/google-pom.spec.ts"],
"total_affected": 1
}
explain_impact — the exact import chain:
{
"found": true,
"import_chain": [
"tests/google-pom.spec.ts",
"src/fixtures/base-fixture.ts",
"src/pages/google-home-page.ts"
]
}
🚀 The Complete AI-QA Pipeline
This is the third tool in a series designed to give AI agents full visibility into a Playwright test suite:
- Trace Decoder — how did a test fail? Full network, DOM, and console analysis from the trace file.
- Flakiness Knowledge Graph — is this test reliable? Historical failure rates, trends, browser-specific patterns.
- AST Impact Mapper — which tests need to run? Precise impact analysis from the dependency graph.
Together, they cover the full lifecycle: knowing what to run, understanding if it's reliable, and diagnosing failures when they happen — all without opening a trace file or running the full suite.
⚡️ Setup
Install:
npm install -g ast-impact-mapper-mcp
Claude Code:
claude mcp add ast-impact-mapper ast-impact-mapper-mcp
Cursor / VS Code (.cursor/mcp.json):
{
"mcpServers": {
"ast-impact-mapper": {
"command": "ast-impact-mapper-mcp"
}
}
}
Ask your AI:
My project is at /my-project. I just pushed a PR.
1. get_affected_tests_by_branch — which tests are affected vs main?
2. explain_impact for the top result — why is that test affected?
3. get_coverage_gaps — what source files have zero test coverage?
4. get_test_summary — what's the overall health of the suite?
Stop running everything. Start running what matters. 🧠🕸️🐸
Top comments (0)