/test-unit

Four differences:

1. Framework detection reads real package.json (not guessed from imports).
2. Style-matching reads a nearby existing test file (not invented).
3. Colocation follows what the project already does (not arbitrary).
4. Mock discipline is enforced by rule (not left to Claude's discretion).

The naive prompt version works too — but produces tests that need cleanup half the time. The command produces tests that don't.

The command reads the target file's nearest test-file neighbor and matches that framework.

So a project with both Jest (for legacy) and Vitest (for new code) works correctly — files near existing Jest tests get Jest tests, files near Vitest tests get Vitest.

If auto-detection picks wrong, add an explicit override rule to the command body, one line per directory boundary: "Under src/legacy/** use Jest. Under src/** (elsewhere) use Vitest."

Sonnet is right. Writing unit tests is applied text generation with clear rules — Sonnet handles it well.

Opus adds cost without meaningfully better output for this task. Reserve Opus for genuinely analytical work (security review, schema design, architectural decisions).

Read + Grep + Glob for exploration, narrow Write for test file locations, and Bash restricted to reading manifest files:

• Read, Grep, Glob
• Write(**/*.test.*), Write(**/*.spec.*), Write(**/__tests__/**), Write(**/tests/**), Write(**/test/**)
• Bash(cat package.json), Bash(cat pyproject.toml), Bash(cat go.mod)

Do not give general Bash.

It reads the target file to understand the public surface (exported functions, classes, module APIs) and generates tests covering:

• Happy paths — the intended usage.
• Edge cases — empty input, boundary values, unicode.
• Error paths — invalid input, throws.
• Observable state changes — if applicable.

Private implementation details are skipped. Passing a focus argument (edge cases, error handling) shifts the balance.

Real tests. That's the point of the style-matching and no-over-mock rules.

Generated tests use your team's assertion style, your existing utilities, and real dependencies wherever practical. They should be indistinguishable from tests a teammate wrote.

If they consistently need cleanup after generation, that's a signal — usually a style rule missing from the command body. Fix the command, not the output.

By default it doesn't check coverage — it writes tests it thinks provide good coverage of the target.

For teams with a hard coverage bar, two approaches:

• Use the coverage-target variant above that adds a self-check step to /test-unit.
• Chain with /coverage-check as a separate step.

Most teams prefer the second approach — separation of concerns keeps /test-unit fast and /coverage-check as a review gate.

Not by default — the allowed-tools Write patterns only include test file paths, not source paths. That's intentional: /test-unit writes tests, doesn't modify source.

If the target file needs refactoring to be testable (tightly coupled to global state, hard-to-mock singletons), the command reports what's blocking testability and asks you to refactor first.

Separation of concerns keeps the command safe and predictable.

Usually not. The framework-detection logic in the reference /test-unit handles the multi-framework case cleanly for most projects.

Install variants only if your project explicitly needs a specific framework regardless of what's nearby — e.g., "all new code uses Vitest even in directories with legacy Jest tests." In that case a dedicated /test-unit-vitest is a useful override.

Commit .claude/commands/test-unit.md to git. Every teammate gets identical test-writing behavior on next pull.

This is exactly the pattern that makes Claude Code output indistinguishable from human output — no per-developer drift, no "why did Claude write it that way" debates in review.