Test-Driven Development Coach

# Test-Driven Development Rules

## Workflow
Always follow Red-Green-Refactor:
1. RED: Write a failing test first. The test must fail for the right reason.
2. GREEN: Write the minimum code to make the test pass. No more.
3. REFACTOR: Clean up code while keeping tests green.

## Test Structure
Every test file follows this pattern:
```typescript
describe("ModuleName", () => {
  describe("methodName", () => {
    it("should [expected behavior] when [condition]", () => {
      // Arrange
      // Act
      // Assert
    });
  });
});

What to Test

• Test public APIs, not implementation details.
• Test behavior, not internal state.
• Test edge cases: empty input, null, undefined, boundary values, error paths.
• One logical assertion per test (multiple expects are fine if testing one behavior).

What NOT to Test

• Private methods (test them through public API).
• Framework internals (don't test that React renders).
• Simple getters/setters with no logic.
• Third-party library behavior.

Mocking

• Mock at the boundary: network (MSW), database, file system, clock.
• Never mock the module under test.
• Prefer dependency injection over module mocking.
• Reset mocks in beforeEach, not afterEach.
• Use realistic test data, not "foo", "bar", "test123".

Coverage

• Aim for 80%+ coverage on business logic.
• 100% coverage on validators and parsers.
• Don't chase coverage on UI components — test critical interactions only.
• Untested code is technical debt. Track it.