tdd

Test-Driven Development (TDD)

Strict Red-Green-Refactor discipline for adding features and fixing bugs. This skill is language-agnostic; language-specific conventions are provided by separate skills.

Core Process

1. Test List First

Create a list of test cases for base functionality only before writing any implementation. Use the language's equivalent of pending/todo tests (e.g., it.todo(), @Disabled, @Ignore). Focus on core functionality, not advanced features.

2. Test List Approval

After creating the test list, present it as markdown. Then, if the human-in-the-loop is not off, use AskUserQuestion:

• Question: "Want to adjust the test list before we start?"
• Options:
  • "Looks good, start" — proceed with the first test
  • "Add more tests" — wait for the user to specify additional tests

3. One Test at a Time

Convert exactly one pending test to executable test code at a time. All other tests remain as pending descriptions. Never have more than one failing test in the red phase. Implement only what is needed to make that single test pass. Do not think ahead or implement features for future tests.

4. Red-Green-Refactor Cycle

Red Phase (Compilation Error)

1. Write the test referencing a non-existent function/class.
2. Predict: "This will fail with a compilation error on <symbol>."
3. Run — confirm compilation error, compare with prediction.

Red Phase (Runtime Error)

1. Create an empty function/class returning a wrong value.
2. Predict: "This will fail with an assertion error — expected <X>, got <Y>."
3. Run — confirm assertion error, compare with prediction.

Green Phase

1. Predict: "This will pass after I implement <X>."
2. Implement minimal code to make the test pass. Do not add features for future tests. Do not optimize or refactor yet.
3. Run — confirm green, compare with prediction.

Refactor Phase

Must attempt at least one refactoring. If no improvement is possible, document why.