Regression Tester

## Overview

25 stars

Best use case

Regression Tester is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

## Overview

Teams using Regression Tester should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/regression-tester/SKILL.md --create-dirs "https://raw.githubusercontent.com/ComeOnOliver/skillshub/main/skills/TerminalSkills/skills/regression-tester/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/regression-tester/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How Regression Tester Compares

Feature / AgentRegression TesterStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

## Overview

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Regression Tester

## Overview

This skill creates a safety net around refactoring work. It analyzes what changed, identifies the public API surface and behavior contracts of the refactored code, generates targeted regression tests that verify behavior is preserved, and runs them against both the old and new implementations to confirm equivalence.

## Instructions

### Step 1: Analyze the Refactoring Scope

1. Get the diff: `git diff main...HEAD` or compare specific commits
2. Categorize changes:
   - **Signature changes** — function/method names, parameters, return types
   - **Internal restructuring** — same API, different implementation
   - **Extracted modules** — code moved to new files/functions
   - **Behavioral changes** — intentional behavior modifications (flag these!)

3. Identify the **behavior contract** for each changed unit:
   - What inputs does it accept?
   - What outputs does it produce?
   - What side effects does it have? (DB writes, API calls, file I/O)
   - What errors does it throw and under what conditions?

### Step 2: Check Existing Coverage

1. Run existing tests: `npm test` / `pytest` / `go test ./...`
2. If tests pass, check coverage of the refactored code:
   ```bash
   npx jest --coverage --collectCoverageFrom='src/refactored-module/**'
   ```
3. Identify untested code paths in the refactored area:
   - Uncovered branches (if/else, switch cases, error handling)
   - Edge cases (empty input, null, boundary values, concurrent access)
   - Integration points (function calls to other modules)

### Step 3: Generate Regression Tests

Create tests that verify behavior, not implementation:

1. **Input/output tests** — For pure functions, test that same inputs produce same outputs
2. **Contract tests** — For APIs, verify request/response shape and status codes
3. **Side-effect tests** — For stateful code, verify correct DB operations, events emitted
4. **Error path tests** — Verify error handling behavior is preserved
5. **Boundary tests** — Empty arrays, zero values, maximum lengths, unicode strings

**Test structure:**
```
describe('[ModuleName] regression', () => {
  describe('preserved behavior', () => {
    // Tests that MUST pass identically before and after refactor
  });
  describe('edge cases', () => {
    // Tests for boundary conditions
  });
  describe('error handling', () => {
    // Tests for error paths
  });
});
```

### Step 4: Verify Against Old Implementation

1. Stash or commit current changes
2. Checkout the pre-refactor code: `git stash && git checkout main`
3. Run the new regression tests against the OLD code — they should all pass
4. Return to refactored code: `git checkout - && git stash pop`
5. Run the regression tests again — they should still all pass
6. If any test fails on the refactored code but passed on the old code → regression found

### Step 5: Report

```
Regression Test Report
═══════════════════════
Refactored: src/services/billing.ts (4 functions, 187 lines changed)

Tests generated: 24
  Passed (old code): 24/24  ✓
  Passed (new code): 23/24  ✗

❌ REGRESSION FOUND:
  test: "calculates prorated amount for mid-cycle upgrade"
  Expected: 14.52
  Received: 14.50
  Location: src/services/billing.ts:89 (rounding changed from Math.ceil to Math.round)

✓ All other behavior preserved.
```

## Examples

### Example 1: Refactored Utility Functions

**User prompt:**
```
I refactored our date utility module from moment.js to dayjs. Can you make sure nothing broke?
```

**Agent actions:**
```bash
git diff main -- src/utils/dates.ts
```

**Agent analysis:**
```
Refactoring scope: src/utils/dates.ts
  - Import changed: moment → dayjs
  - 8 exported functions, all signatures preserved
  - Internal parsing logic changed

Existing test coverage: 3 tests covering 2 of 8 functions (25%)

Generated 18 regression tests covering:
  ✓ formatDate() — 4 formats × 3 edge cases (null, invalid, timezone)
  ✓ diffInDays() — positive, negative, same day, DST boundary
  ✓ startOfWeek() — Sunday vs Monday locale, year boundary
  ✓ parseISO() — valid, invalid, with/without timezone offset
  ✓ isBusinessDay() — weekday, Saturday, Sunday, holiday handling
  ✓ addBusinessDays() — skip weekends, cross month boundary

Results against old code (moment.js): 18/18 passed
Results against new code (dayjs):     17/18 passed

❌ Regression: startOfWeek('2024-01-01') returns Sunday with dayjs
   but returned Monday with moment (locale-dependent).
   Fix: Add dayjs.extend(weekOfYear) and set locale explicitly.
```

### Example 2: Extracted Service Layer

**User prompt:**
```
I split our monolithic UserController into UserService + UserController. Did I break anything?
```

**Agent output:**
```
Analyzed refactoring: 1 file → 2 files
  Old: src/controllers/UserController.ts (342 lines)
  New: src/controllers/UserController.ts (98 lines) + src/services/UserService.ts (267 lines)

Public API surface: 6 endpoints unchanged (routes, params, response shapes)
Internal: Business logic extracted to UserService, controller delegates

Generated 22 regression tests:
  POST /users — creation with valid data, duplicate email, missing fields
  GET /users/:id — existing user, non-existent (404), invalid ID format
  PUT /users/:id — partial update, full update, unauthorized (403)
  DELETE /users/:id — soft delete, already deleted, cascade check
  GET /users — pagination, filtering, sorting, empty result

Results: 22/22 passed on both old and new code ✓
No regressions detected. Refactoring is safe.
```

## Guidelines

- Test behavior, not implementation — don't assert on internal method calls
- Run tests against BOTH old and new code to confirm equivalence
- Flag intentional behavior changes separately from regressions
- Focus test generation on the changed code, not the entire codebase
- Include edge cases that the original code may not have tested
- For database-touching code, use transactions that roll back after each test
- If the refactoring changes performance characteristics, add benchmark comparisons
- Keep regression tests permanent — they protect against future changes too

Related Skills

performing-visual-regression-testing

25
from ComeOnOliver/skillshub

This skill enables Claude to execute visual regression tests using tools like Percy, Chromatic, and BackstopJS. It captures screenshots, compares them against baselines, and analyzes visual differences to identify unintended UI changes. Use this skill when the user requests visual testing, UI change verification, or regression testing for a web application or component. Trigger phrases include "visual test," "UI regression," "check visual changes," or "/visual-test".

tracking-regression-tests

25
from ComeOnOliver/skillshub

This skill enables Claude to track and run regression tests, ensuring new changes don't break existing functionality. It is triggered when the user asks to "track regression", "run regression tests", or uses the shortcut "reg". The skill helps in maintaining code stability by identifying critical tests, automating their execution, and analyzing the impact of changes. It also provides insights into test history and identifies flaky tests. The skill uses the `regression-test-tracker` plugin.

performing-regression-analysis

25
from ComeOnOliver/skillshub

This skill empowers Claude to perform regression analysis and modeling using the regression-analysis-tool plugin. It analyzes datasets, generates appropriate regression models (linear, polynomial, etc.), validates the models, and provides performance metrics. Use this skill when the user explicitly requests regression analysis, prediction based on data, or mentions terms like "linear regression," "polynomial regression," "regression model," or "predictive modeling." This skill is also helpful when the user needs to understand the relationship between variables in a dataset.

regression-analysis-helper

25
from ComeOnOliver/skillshub

Regression Analysis Helper - Auto-activating skill for Data Analytics. Triggers on: regression analysis helper, regression analysis helper Part of the Data Analytics skill category.

detecting-performance-regressions

25
from ComeOnOliver/skillshub

This skill enables Claude to automatically detect performance regressions in a CI/CD pipeline. It analyzes performance metrics, such as response time and throughput, and compares them against baselines or thresholds. Use this skill when the user requests to "detect performance regressions", "analyze performance metrics for regressions", or "find performance degradation" in a CI/CD environment. The skill is also triggered when the user mentions "baseline comparison", "statistical significance analysis", or "performance budget violations". It helps identify and report performance issues early in the development cycle.

network-latency-tester

25
from ComeOnOliver/skillshub

Network Latency Tester - Auto-activating skill for Performance Testing. Triggers on: network latency tester, network latency tester Part of the Performance Testing skill category.

keyboard-navigation-tester

25
from ComeOnOliver/skillshub

Keyboard Navigation Tester - Auto-activating skill for Frontend Development. Triggers on: keyboard navigation tester, keyboard navigation tester Part of the Frontend Development skill category.

hypothesis-tester

25
from ComeOnOliver/skillshub

Structured hypothesis formulation, experiment design, and results interpretation for Product Managers. Use when the user needs to validate an assumption, design an A/B test, evaluate experiment results, or decide whether to ship based on data. Triggers include "hypothesis", "A/B test", "experiment", "validate assumption", "test this", "should we ship", or when making a decision that should be data-informed.

skill-tester

25
from ComeOnOliver/skillshub

Skill Tester

../../../engineering/skill-tester/assets/sample-skill/SKILL.md

25
from ComeOnOliver/skillshub

No description provided.

route-tester

25
from ComeOnOliver/skillshub

Test authenticated routes in the your project using cookie-based authentication. Use this skill when testing API endpoints, validating route functionality, or debugging authentication issues. Includes patterns for using test-auth-route.js and mock authentication.

webhook-tester

25
from ComeOnOliver/skillshub

Test webhook integrations locally with tunneling, inspection, and debugging tools.