test-discipline

Enforces writing failing-then-passing tests for every bug fix and feature change.

Updated Mar 10, 2026
One-click install
npx skills add https://github.com/jasoncrawford/brunel --skill test-discipline-jasoncrawford
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-discipline
Source: https://github.com/jasoncrawford/brunel/tree/main/.claude-plugin/skills/test-discipline
Command: npx skills add https://github.com/jasoncrawford/brunel --skill test-discipline-jasoncrawford

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes often ship without tests that actually verify the new behavior, leaving regressions and unverified fixes. This Skill ensures every bug fix or feature is backed by a test that fails before the change and passes after it, and that no existing tests are skipped or failing. ## Core Features & Use Cases - Mandatory New-Behavior Tests: Requires at least one test per bug fix or feature that would fail before the change and pass after it, with explicit justification if existing tests are claimed sufficient. - Zero Skipped or Failing Tests: Directs investigation and fixing of skipped tests (.skip, xit, @pytest.mark.skip), flaky tests, and serial-suite failures rather than working around them. - Test-Level Matching: Guides choosing unit vs. integration tests based on where the bug actually lives, including behavioral stdout assertions for display/TUI output instead of testing internal mechanisms. - Mocking Strategy Guidance: Prescribes real databases for DB-behavior tests and vi.spyOn plus fromTest() factories for logic above the DB, avoiding parallel in-memory store implementations. - Use Case: When fixing a bug where a worker could not connect to a task queue due to a wrong path, the Skill directs writing an integration test with real instances of both components rather than a unit test asserting the path string. ## Quick Start Apply the test-discipline skill to review my bug fix and write a test that fails without the fix and passes with it.

Frequently Asked Questions about test-discipline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a test that verifies a bug fix?▼

Write a test that fails before your change and passes after it. A passing suite of existing tests only proves no regressions; it does not verify the fix works. If no new test seems needed, identify the specific existing tests covering the behavior and explain why they suffice.

Should I use a unit test or integration test for a bug?▼

Match the test level to where the failure occurs. Wrong logic inside a function needs a unit test; two components not wired together need an integration test with real instances of both. A unit test on an integration bug only tests string concatenation, not the actual connection.

When should I mock the database versus use a real one?▼

Use a real DB when testing DB behavior like constraints, timestamps, and queries. Mock the model layer with vi.spyOn and a fromTest() factory when testing logic above the DB such as routing or event handling. Avoid parallel in-memory store implementations that drift from the real code.

How do I test terminal or TUI display output?▼

Capture stdout and assert on the semantic text the user actually sees, such as checking that status text appears in the output. Do not assert on escape codes, internal callbacks, or display state variables, since those test the implementation mechanism rather than the visible behavior.

What should I do about skipped or flaky tests?▼

Fix them rather than working around them. Tests marked with .skip, xit, xdescribe, or @pytest.mark.skip must be investigated and repaired, and flaky tests that usually pass are treated as bugs. Claims like 'it was already skipped' or 'it is unrelated to my change' are not acceptable.