PrompTom
Wszystkie skille

The test that would have caught it

regression-testFREEtestingregression

After a fix, writes the check on the exact input that broke — and proves the check is not hollow.

Co robi

  • Triggers after fixing a defect, on “write tests”, and especially when a bug has returned a second time.
  • Names the test after the behaviour rather than the function: six months on, the name must explain what broke.
  • Takes the exact input that failed: the empty list, the 40-character name, the second call, the missing environment variable. Not a tidy representative case.
  • Breaks the code on purpose and watches the test fail. A test that passes against broken code is worse than none: everyone trusts it and nothing is behind it.
  • Warns specifically about emptiness assertions: expecting an empty list also passes when the feature is gone entirely.
  • Argues you out of testing the framework, snapshotting large structures, and anything depending on the network or a real clock.

Do czego się przyda

A fix without a test lasts until the next person opens that file. But tests can be decorative too: plenty of suites pass against code that has been deleted, and nobody notices, because green. This demands the opposite proof — break the code and watch it fail.

Gdzie go umieścić

  1. 1Utwórz w projekcie folder .claude/skills/regression-test
  2. 2Umieść w nim plik SKILL.md z tekstem poniżej
  3. 3Gotowe. Claude Code sam załaduje skill, gdy zadanie będzie pasować do opisu

Aby skill działał we wszystkich projektach, a nie w jednym, umieść go w ~/.claude/skills zamiast w folderze projektu.

Plik SKILL.md

---
name: regression-test
description: Write the test that would have caught the bug you just fixed. Use after fixing a defect, when the user asks for tests, or when a bug has come back a second time.
---

# The test that would have caught it

A fix without a test is a fix that lasts until the next person touches
that file. Write the test first if you can — a test that fails before
the fix and passes after is proof; a test written afterwards often only
proves the code does what it does.

## Start from the failure, not the function

Name the test after the behaviour that broke, in the language of the
problem: not `testParseInput`, but `an empty code returns no rows`.
Six months later that name is what tells someone whether the failure
matters.

## What to test

**The exact input that broke it.** The empty list, the 40-character
name, the second call, the missing environment variable. Not a tidy
representative case.

**One thing per test.** A test asserting five things fails on the first
and hides the rest.

**The boundary, not the middle.** Zero, one, the limit, the limit plus
one. Bugs live at edges; the middle was already working.

## Prove the test is not hollow

Break the code on purpose and watch the test fail. A test that passes
against broken code is worse than no test: it is a guard everyone
trusts and nothing is behind it.

This applies most to tests that assert something is absent. `expect(x)
.toEqual([])` passes when the whole feature is missing. Assert first
that the thing you are filtering exists at all.

## What not to write

- Tests of the framework, the language, or the library. They are
  already tested.
- Tests that mirror the implementation line for line. They fail on
  every refactor and catch nothing.
- Snapshot tests of large structures. Nobody reads the diff; everyone
  presses update.
- A test that needs the network, a real clock or a real payment
  provider. Pull the boundary in until the test is deterministic, or
  say plainly that this path is not covered.

## Finishing

Run the whole suite, not just the new test. Then say which specific
regression is now guarded — one sentence, in terms of the bug, not of
the code.
The test that would have caught it — PrompTom