tdd-workflow

Files (1)

• SKILL.md

SKILL.md (first lines)

# Test-Driven Development Workflow

## Core Philosophy

TDD is a design discipline, not just a testing technique. Writing tests first forces you to think about the interface before the implementation, producing code that is inherently testable, loosely coupled, and driven by actual requirements.

## The Red-Green-Refactor Loop

### Step 1: RED — Write a Failing Test

1. Identify the smallest piece of behavior to implement next.
2. Write a test that describes that behavior from the caller's perspective.
3. Run the test suite. The new test MUST fail.
4. If the test passes without writing new code, either the behavior already exists or the test is wrong.

**Checklist before moving to GREEN:**
- [ ] The test describes WHAT, not HOW.
- [ ] The test name reads like a specification (e.g., `it should return 404 when resource not found`).
- [ ] The test fails for the right reason (expected assertion failure, not a syntax error or import error).
- [ ] The test is isolated — it does not depend on other tests or external state.

### Step 2: GREEN — Write the Minimal Implementation

1. Write the simplest code that makes the failing test pass.
2. It is acceptable — even encouraged — to hardcode values, use naive algorithms, or write "ugly" code at this stage.
3. Do NOT add logic that is not required by a failing test.
4. Run the full test suite. ALL tests must pass.

**The "simplest thing that could work" principle:**
- If one test expects `return 42`, write `return 42`. Do not write a general formula yet.
- If two tests expect different outputs, write an `if` statement. Do not write a loop yet.
- If three tests show a pattern, NOW consider a general algorithm.

**Checklist before moving to REFACTOR:**
- [ ] The new test passes.
- [ ] All previously passing tests still pass.
- [ ] No code was added beyond what the tests demand.

### Step 3: REFACTOR — Improve the Design

1. Look for duplication in both production code and test code.
2. Extract methods, rename variables, simplify conditionals.
3. Apply design patterns only when the code asks for them (three or more instances).
4. Run the full test suite after every change. All tests must stay green.

**Refactoring targets:**
- [ ] Duplicate code extracted into shared functions.
- [ ] Variable and method names clearly express intent.
- [ ] No method exceeds 10-15 lines.
- [ ] No function has more than 3 parameters.
- [ ] Test code is also clean and readable.

### Step 4: REPEAT

Return to Step 1 with the next smallest behavior.

---

## Test Naming Conventions

Use descriptive names that serve as documentation:

```
// Pattern: [unit]_[scenario]_[expected result]
test_calculateTotal_withEmptyCart_returnsZero
test_calculateTotal_withSingleItem_returnsItemPrice
test_calculateTotal_withDiscount_appliesDiscountToSubtotal

// BDD-style
describe("calculateTotal") {
  it("should return zero for an empty cart")
  it("should return the item price for a single item")
  it("should apply discount to subtotal")
}

// Given-When-Then
given_emptyCart_when_calculateTotal_then_returnsZero
```

**Rules:**
- Never use "test1", "test2", or other meaningless names.
- The test name should tell you what broke without reading the test body.
- Group related tests under a `describe` or test class.

---

## Choosing What to Test Next

### Start with the degenerate cases:
1. Null / empty / zero inputs.
2. Single element / simplest valid input.
3. Typical valid inputs.
4. Boundary values and edge cases.
5. Error conditions and invalid inputs.

### Prioritization:
- Begin with the behavior that drives the most architectural decisions.
- Defer I/O, persistence, and external service tests until core logic is solid.
- Test the happy path first, then edge cases, then error paths.

---

## TDD for Different Test Types

### Unit Tests (most common in TDD)
```
RED:   Write a test for a single function or method.
GREEN: Implement just that function.
REFACTOR: Clean up the function and its test.
Cycle time: 1-5 minutes.
```

### Integration Tests
```
RED:   Write a test that exercises two or more components together.
GREEN: Wire the components and implement any missing glue code.
REFACTOR: Extract shared setup, clean interfaces between components.
Cycle time: 5-15 minutes.
```

From Claude-Code-Community-Ireland/claude-code-resources, MIT.

More from Claude-Code-Community-Ireland/claude-code-resources