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.