Cursor Rules for TDD: Keep the Red, Green, Refactor Loop

Cursor rules for TDD hold the assistant to the red-green-refactor cycle: write a test that fails, write the minimal code to make it pass, then improve the code without changing its behavior. Without a rule, the assistant skips ahead to an implementation and writes tests afterward, which is the pattern TDD is specifically designed to avoid.

The rule keeps the sequence. fenbs keeps the meaning: the acceptance criteria in the task tell the assistant what the tests are supposed to prove, and the lessons from previous attempts explain what did not work before.

Why the sequence matters

Writing a test after the implementation is not TDD. The test tends to verify what the code does rather than what it should do. It often passes immediately because it was written to fit the code. That gives false confidence: the test is green, but it does not protect you from the next change that breaks the behavior.

A failing test first means the test proved the feature did not exist. The green step proves the feature was added. The refactor step proves the code can be improved without losing the feature. That sequence produces a test suite that actually catches regressions, not just a collection of code that happens to assert things.

The visible failing test also prevents a subtler failure: writing a test that was never actually red. An assistant that writes an implementation and then writes a test for it may produce a test that could never fail, because it was written to describe what the code does rather than what it should do. The rule that requires showing failure output makes this impossible to skip quietly.

What the rule file should say

The rule needs to state the steps in order and require confirmation at each boundary. An assistant that does all three steps in one response cannot show you a failing test before the fix. Requiring a stopping point after the red step makes the cycle visible and reviewable.

---
description: Test-driven development cycle rules
globs: "**/*.test.ts,**/*.spec.ts,**/*.test.py,**/*.spec.js"
alwaysApply: false
---

## TDD cycle
1. Write a failing test first. Stop and show the test and the failure output before proceeding.
2. Write the minimal code to make the test pass. Do not add anything the test does not require.
3. Run the tests. Only proceed to refactor if all tests pass.
4. Refactor to improve the code without changing behavior. Run the tests again to confirm they still pass.

## Minimal implementation
- Write only what the current test requires. If the simplest solution is to return a hardcoded value, do that.
- Add generalization only when a new test forces it (triangulation).

## No tests after the fact
- Do not write implementation code and then add tests to match it.
- If a test is written to pass existing code without first failing, note that in the task.

## Completion check
- All tests must pass before a task is marked done.
- The task notes should record which behavior each new test proves.

Minimal implementation and triangulation

TDD uses a technique called triangulation: if the simplest passing implementation is to return a hardcoded value, that is correct for the first test. The second test forces generalization because the hardcoded value no longer works. This iterative narrowing is how TDD drives design from actual requirements rather than anticipated ones.

Triangulation also makes it easier to see when the design is wrong. If three tests force a solution that is clearly more complex than the problem deserves, the tests are describing the problem incorrectly. That signal is visible when you proceed test by test; it disappears when an assistant writes the general solution first and the tests afterward.

An assistant without a rule treats "minimal implementation" as a suggestion and jumps to the general solution. A rule that explicitly permits the hardcoded response for the first test gives the assistant permission to take the step that feels wrong but is correct. Over several tasks, that habit builds a test suite that is much easier to change safely.

Acceptance criteria in the task

The rule sets the sequence. The task sets the goal. Before starting TDD work, the task should describe what behavior the new tests will prove and what a complete implementation looks like. Without that, the assistant can follow the cycle correctly and still build the wrong thing.

When acceptance criteria are missing, the assistant starts with the red step but has to invent what to test. It guesses at edge cases, omits important ones, and spends cycles on cases that were not in scope. A five-minute investment in writing clear criteria before the first test almost always reduces the total time on the task.

Acceptance criteria answer: what should the new code do, under what conditions, and how will that be verified? Recording those answers in the task before the assistant starts means the failing test can be written against them. After the task is done, the criteria stay in the record as evidence that the feature was built to specification.

How to do TDD work with fenbs

1. Create a free account and add your project.
2. Before starting a TDD task, write the acceptance criteria in the task's plan: the behavior to add, the inputs and outputs to test, and the edge cases.
3. Place the .cursor/rules/tdd.mdc file in your project and adjust the globs to match your test file naming.
4. Connect Cursor via Integrations and ask it to read the task acceptance criteria before writing the first test.
5. When a test reveals an assumption that was wrong, record a Lesson learned in fenbs and update the acceptance criteria to reflect the correct understanding.

For more rule patterns for testing workflows, see cursor rules for AI projects and cursor rules examples. For managing rule files across a complex project, see cursor rules hierarchy. See cursor rules library for sharing TDD rules across multiple repositories.