/test-advanced is not a built-in Claude Code command. This entry is a
custom command recipe: you create a Markdown file in .claude/commands/, Claude
Code exposes it as /test-advanced, and the behavior comes from the prompt you
write into that file.
Use it when the simpler /generate-tests style prompt is too broad and you want
Claude to plan a test matrix before writing code: current behavior, invariants,
edge cases, regression cases, framework conventions, and any advanced gaps your
project already has tooling to measure.
Create the command
Create .claude/commands/test-advanced.md:
---
description: Plan and draft deeper tests for a file, function, or behavior
argument-hint: [file-or-function]
---
Plan advanced test coverage for $ARGUMENTS.
First inspect the target code and nearby tests. Then produce:
1. A short behavior summary grounded in the source.
2. Existing test framework and naming conventions.
3. A scenario table covering happy paths, boundaries, invalid input, and
regression cases.
4. Property-style invariants if the behavior has stable rules worth checking.
5. Integration or contract cases only where existing project tests already use
those patterns.
6. Mutation-score or coverage gaps only if the repository already has a tool for
measuring them.
7. The smallest test command to run after the draft is written.
After the plan, draft the minimal tests that fit the project's current test
stack. Do not introduce a new framework unless the project has no test framework
yet and you explain the tradeoff.
Claude Code derives the command name from the filename, so this file creates
/test-advanced. Text after the command name is passed through $ARGUMENTS.
Usage
/test-advanced src/utils/parser.ts
/test-advanced "the retry backoff behavior in packages/client/retry.ts"
/test-advanced apps/api/users.test.ts -- focus on regression cases from the current diff
The text after the command is normal prompt input, not a CLI parser. There are
no documented built-in flags such as --mutation, --pytest, or --coverage;
ask for those focuses in plain language, and only rely on tools that already
exist in the repository.
Suggested workflow
- Ground the target. Ask Claude to read the target file, adjacent tests, and
package configuration before proposing new cases.
- Define success criteria. State what behavior should stay true, which
failures matter, and what a useful regression test would catch.
- Match the project. Reuse the existing test framework, assertion style,
fixture pattern, and command names.
- Separate plan from edits. Have Claude show the scenario table first, then
write the smallest useful tests.
- Run narrowly. Use the smallest test command for the touched file or
package before running the full suite.
Example output shape
Ask the command to return a compact plan before writing tests:
| Area |
What to check |
Why it matters |
| Current behavior |
Inputs, outputs, thrown errors, and side effects visible in source |
Keeps tests tied to real code instead of guesses |
| Boundaries |
Empty input, nullish input, min/max values, encoding, and rounding |
Catches common regressions without broad fixture churn |
| Invariants |
Relationships that should always hold across valid inputs |
Good fit for property-style testing when the project already has tooling |
| Integration |
Existing API, storage, or component boundaries already covered nearby |
Avoids inventing integration harnesses in one command |
| Regression |
Known bug, diff hunk, or review concern the test should protect |
Makes the test valuable after the immediate change |
Then let Claude draft tests only for cases that can run in the current project.
For JavaScript or TypeScript this might mean Jest or Vitest if those configs
already exist. For Python this usually means pytest when the repository already
uses it.
Source Verification Notes
Verified on 2026-06-19:
- Claude Code's skills/custom-command documentation says custom commands have
been merged into skills, and existing
.claude/commands/*.md files still
create slash invocations based on the filename.
- Anthropic's testing guidance recommends defining specific, measurable success
criteria and designing evaluations around representative tasks, edge cases,
and regression checks.
- This page applies those mechanics and testing principles to a user-authored
/test-advanced recipe. It does not claim an official built-in
/test-advanced or /test command.
Duplicate Check
/generate-tests is the simpler broad test-generation recipe. /test-advanced
is narrower: it asks Claude to plan a source-grounded test matrix first and only
then draft tests that fit the repository's existing framework and tooling.
Troubleshooting
- If the output invents a framework, tighten the prompt: "Use only the test
framework already configured in this repository."
- If the plan is too broad, ask for the smallest regression-focused case first.
- If the command cannot find a test script, point it at
package.json,
pyproject.toml, pytest.ini, vitest.config.*, or the repository docs.