https://github.com/fmguerreiro/tdad-ts
Test-Driven Agentic Development for TypeScript — graph-based test impact map for AI coding agents (TS port of arXiv 2603.17973)
https://github.com/fmguerreiro/tdad-ts
ai-agents ai-coding-agents cli code-analysis dependency-graph developer-tools llm regression-testing static-analysis test-driven-development test-impact-analysis typescript
Last synced: 16 days ago
JSON representation
Test-Driven Agentic Development for TypeScript — graph-based test impact map for AI coding agents (TS port of arXiv 2603.17973)
- Host: GitHub
- URL: https://github.com/fmguerreiro/tdad-ts
- Owner: fmguerreiro
- License: mit
- Created: 2026-05-08T05:36:40.000Z (2 months ago)
- Default Branch: main
- Last Pushed: 2026-05-25T00:25:58.000Z (about 1 month ago)
- Last Synced: 2026-05-25T02:27:57.299Z (about 1 month ago)
- Topics: ai-agents, ai-coding-agents, cli, code-analysis, dependency-graph, developer-tools, llm, regression-testing, static-analysis, test-driven-development, test-impact-analysis, typescript
- Language: TypeScript
- Size: 55.7 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# tdad-ts
TypeScript port of TDAD (Test-Driven Agentic Development), a graph-based test
impact analyzer for AI coding agents.
Reference: Alonso, Yovine, Braberman.
"TDAD: Test-Driven Agentic Development - Reducing Code Regressions in AI
Coding Agents via Graph-Based Impact Analysis." arXiv:2603.17973, March 2026.
## What it does
Indexes a TypeScript project into a static `test_map.txt` that maps each
source file to the tests at risk of regressing if that file changes. An AI
agent grep's the map after editing a file, runs the listed tests, and
self-corrects on failure - no MCP server, graph DB, or runtime API.
## Status
Prototype. Single-pass indexer, in-memory graph, file-level test map.
## Usage
```bash
tdad-ts index --out test_map.txt
tdad-ts index --out test_map.txt --coverage coverage.json
tdad-ts impacted [ ...]
tdad-ts impacted --coverage coverage.json
```
### Coverage strategy
Pass a JSON file via `--coverage ` to enable the Coverage strategy. The
file maps each test file to the source files it covered at runtime:
```json
{
"version": 1,
"tests": {
"tests/foo.spec.ts": ["src/used.ts", "src/lib/helper.ts"],
"tests/bar.spec.ts": ["src/lib/helper.ts"]
}
}
```
Paths are project-relative, forward-slash. Generating this file from a test
runner's raw output (e.g. vitest's v8 coverage report) is a downstream concern
left to the caller.
## Algorithm
Same scoring as the paper:
```
score = (1 - c_w) * w_strategy + c_w * confidence
```
with `c_w = 0.3` and per-strategy weights:
| Strategy | Weight | Confidence |
|------------|--------|------------|
| Direct | 0.95 | 1.00 |
| Route | 0.90 | 0.70 |
| Transitive | 0.70 | 0.56 |
| Coverage | 0.80 | 0.50 |
| Imports | 0.50 | 0.45 |
Tiers: high (>= 0.8), medium (0.5-0.8), low (< 0.5). Default cap 50 tests
per source file.
## Test linker heuristics
Three-tier strategy from the paper, ported to TS conventions:
1. Naming convention: `foo.spec.ts`, `foo.test.ts`, `__tests__/foo.ts` -> `foo.ts`
2. Prefix matching: progressive truncation of test-file stem
3. Directory proximity: nearest non-test ancestor when a stem matches multiple sources
## Route and registry edges
Static `import` chains miss two recurring patterns in real codebases: Next.js
route resolution (a test reaches the page through a URL, not an import) and
registry-based dispatch (a function looks up its target by name in a table).
Both are exposed via a single JSON config passed with `--registries`:
```json
{
"routes": { "appDir": "app" },
"registries": [
{
"name": "email-templates",
"lookup": { "import": "src/email-builder", "function": "buildEmail", "argIndex": 0 },
"registered": { "files": "src/templates/*.ts" }
}
]
}
```
`routes` walks the Next.js app directory, derives URL patterns (stripping
`(group)` segments and replacing `[id]` with wildcards), and emits a `Route`
edge from any test that contains a matching string literal. `registries`
detects calls to a configured lookup function whose key argument matches a
registered file's basename, and emits the same edge type. Both surface as the
`Route` strategy in `test_map.txt` at the high tier.