# test-regression-runner MCP for AI Agents AI Agent Connect

> test-regression-runner MCP automates the verification of code changes by identifying and running only the tests affected by your edits. It compares current results against a historical baseline to catch new regressions, removed tests, or flaky behavior before they hit production.

## Overview
- **Category:** developer-tools
- **Price:** Free
- **Endpoint:** https://edge.vinkius.com/vk_preview_FUTu0rNg9ewlNxeYf3VMM26Dw5zkdRvD4N14LHYB/ai-agent-connect
- **Tags:** testing, regression, automation, ci-cd, verification

## Description

Testing shouldn't feel like a guessing game where you run a massive suite of tests hoping nothing broke. This MCP changes that by focusing your attention exactly where it matters. When you modify a file, your agent doesn't need to trigger every single test in your repository. Instead, it identifies the specific subset of tests impacted by your changes and runs them immediately. This saves a massive amount of time and compute. Once the tests finish, the system looks back at your previous successful runs to see if anything actually changed. It flags new failures, identifies tests that have disappeared, and spots non-deterministic flakiness that might be causing headaches. By connecting this to your workflow through Vinkius, you get a reliable way to verify code integrity without the manual overhead of managing test baselines or hunting down intermittent failures. It turns a slow, heavy verification process into a fast, surgical strike.

## Tools

### analyze_regression_differences
Compares current test results against the baseline to find specific failures. It helps you see exactly what changed between runs.

### get_test_baseline
Fetches the results from the last successful test run. This provides the reference point needed to detect regressions.

### run_targeted_tests
Triggers only the tests that are affected by your code changes. This avoids the waste of running an entire test suite.

## Prompt Examples

**Prompt:** 
```
Run the tests affected by the changes in src/logic.ts.
```

**Response:** 
```
Tests for `src/logic.ts` have been executed.

| Status | Count |
| :--- | :--- |
| **PASS** | 12 |
| **FAIL** | 0 |

All targeted tests passed successfully.
```

**Prompt:** 
```
Compare my current test results with the baseline for suite 'core-api'.
```

**Response:** 
```
Comparison complete. I found a discrepancy in the `core-api` suite:

* **New Failure:** `auth_test.spec.ts` (Expected `status: 200`, got `status: 403`)
* **Removed Tests:** 0
* **Flakiness Detected:** None
```

**Prompt:** 
```
Get the baseline for the 'ui-components' suite.
```

**Response:** 
```
Here is the baseline data for the `ui-components` suite:

* **Last Successful Run:** 2023-10-24 14:20 UTC
* **Pass Count:** 45
* **Fail Count:** 0
* **Code Coverage:** 88.5%
```

## Capabilities

### Run only impacted tests
Execute the specific subset of tests that are actually affected by your recent file modifications.

### Compare results against baselines
Check current test outcomes against the last known successful run to find discrepancies.

### Detect test flakiness
Identify non-deterministic tests that fail inconsistently across different runs.

### Spot removed tests
Recognize when tests that previously passed are no longer being executed.

### Analyze regression causes
Perform deep comparisons between current and historical results to pinpoint new failures.

## Use Cases

### Rapid local verification
A developer modifies a core utility and asks their agent to run only the tests impacted by that specific file to save time.

### Debugging flaky tests
An engineer notices a test failing intermittently and uses the MCP to compare recent runs against the baseline to confirm flakiness.

### Post-refactor validation
After a large refactor, a user checks for regressions to ensure that the logic changes didn't break existing functionality.

### CI/CD health checks
A DevOps engineer uses the comparison tools to ensure that a new deployment hasn't introduced subtle regressions compared to the previous version.

## Benefits

- Cut down testing time by using run_targeted_tests to skip irrelevant suites.
- Catch new bugs early by using analyze_regression_differences to compare current runs against history.
- Stop chasing ghosts by using the system to identify non-deterministic flakiness.
- Maintain a clean test suite by detecting when tests have been removed from the execution path.
- Get reliable verification by using get_test_baseline to ensure you are comparing against a known good state.

## How It Works

The bottom line is you stop running unnecessary tests and start catching regressions instantly.

1. Connect your agent to the MCP via the Vinkius catalog.
2. Point your agent to the files you just modified.
3. Receive a detailed report of passed tests and identified regressions.

## Frequently Asked Questions

**How does test-regression-runner speed up my testing?**
It identifies only the specific tests impacted by your code changes, so you don't have to wait for a full, massive test suite to finish every time you make an edit.

**Can I use test-regression-runner to find flaky tests?**
Yes. By comparing current test results against a historical baseline, the MCP can detect non-deterministic failures that pass sometimes and fail others.

**Does test-regression-runner work with any testing framework?**
As long as your testing environment can be triggered via your AI client, this MCP can manage the execution and comparison of those test results.

**How does test-regression-runner handle new bugs?**
It compares your current run to the last successful baseline. If a test that used to pass now fails, it flags it as a new regression immediately.

**Can I use test-regression-runner in my local development workflow?**
Absolutely. You can connect it to your AI client in Cursor or VS Code to verify your local changes before you ever push your code to a repository.

**How does targeted testing work?**
The system maps modified source files to their corresponding test files using naming conventions, ensuring only relevant tests are run via `run_targeted_tests`.

**What is a regression in this context?**
A regression is a failure in a part of the system that was previously working, identified by comparing the current run against a baseline.

**How can I detect flaky tests?**
You can use `analyze_regression_differences` to identify patterns where tests pass and fail inconsistently without code changes.