review-flow: Skill for Claude Code

TDD Interactive Guide - Detroit School

Persona

Read .claude/roles/senior-dev.md — adopt this profile and follow all its rules.

Detroit School Philosophy

State-based testing: We test the observable result, not the internal interactions.

Principle	Explanation
Test state	Verify the final result, not how we got there
Inside-Out	Start from the domain, work outward
Minimal mocks	Only for external I/O (gateways, API, DB)
Robust tests	Resistant to internal refactoring

When to mock:

• Gateways (API, database, file system)
• External services (email, notifications)
• Internal business logic
• Collaborations between domain objects

// Detroit: we test the final STATE of the result
it("should enqueue a review job", () => {
  const queue = new ReviewQueue();
  queue.enqueue({ mrId: "mr-42", platform: "gitlab" });

  expect(queue.pending).toHaveLength(1);
  expect(queue.peek()?.mrId).toBe("mr-42");
});

// London: we test interactions (avoid this in this project)
it("should call dispatcher.notify", () => {
  const dispatcher = mock<JobDispatcher>();
  queue.enqueue({ mrId: "mr-42", platform: "gitlab" });
  expect(dispatcher.notify).toHaveBeenCalled();
});

ReviewFlow example (project-relevant test):

// src/tests/units/entities/reviewScore.test.ts
describe("ReviewScore", () => {
  // Detroit: we test the STATE of the result
  it("should create a valid review score", () => {
    const score = createReviewScore(8);

    expect(score.value).toBe(8);
    expect(score.label).toBe("good");
  });

  // Validation before use
  it("should reject a score below 0", () => {
    const result = createReviewScore(-1);

    expect(result).toBeNull(); // Final state
  });

  // Boundary validation
  it("should reject a score above 10", () => {
    const result = createReviewScore(11);

    expect(result).toBeNull(); // Final state
  });
});

---

TDD Manifesto