Accepts optional arguments:
- A file path: generate tests for that source file
run: run the existing test suite and analyze results
- No arguments: suggest what to test based on recent changes
Detect the test framework and conventions before doing anything else.
Check these sources in order:
package.json (Node/JS/TS projects):
scripts.test for the test command
devDependencies for jest, vitest, mocha, ava, tap, node:test, playwright, cypress
jest or vitest config keys
Config files:
jest.config.*, vitest.config.*, .mocharc.*, ava.config.*
pytest.ini, pyproject.toml (look for [tool.pytest]), setup.cfg
go.mod (Go projects use go test by default)
Cargo.toml (Rust projects use cargo test)
Existing test files:
- Scan for
*.test.*, *.spec.*, *_test.*, test_*.* files
- Read 1-2 existing test files to understand patterns, imports, assertion style, and structure
- Note the directory structure (co-located tests vs
__tests__/ vs tests/ vs test/)
Record your findings:
- Framework name and version
- Test file naming convention
- Test file location convention
- Import/require style
- Assertion style (expect, assert, chai, etc.)
- Any custom utilities, fixtures, or helpers used
Route based on the argument provided.
- File path given -> Go to
generate_tests
- "run" given -> Go to
run_tests
- No arguments -> Go to
suggest_tests
Generate tests for the specified source file.
A. Read and analyze the source file:
- Identify all exported/public functions, classes, methods, and types
- Understand each function's parameters, return types, and side effects
- Note error handling patterns (throws, returns null, returns Result, etc.)
- Identify dependencies that will need mocking
B. Read existing test files in the project (1-2 files minimum):
- Match their import style exactly
- Match their describe/it or test block structure
- Match their assertion patterns
- Match their mock/stub approach
- Use the same test utilities and helpers
C. Generate tests covering:
- Happy paths: Normal expected inputs produce correct outputs
- Edge cases:
- Empty inputs (empty string, empty array, null, undefined, zero)
- Boundary values (min/max integers, very long strings)
- Single element collections
- Error handling:
- Invalid inputs that should throw or return errors
- Missing required parameters
- Type mismatches (if applicable)
- Async behavior (if the function is async):
- Successful resolution
- Rejection/error cases
- Timeout scenarios (if relevant)
- Dependencies:
- Mock external dependencies (APIs, databases, file system)
- Verify correct interaction with dependencies (called with right args)
D. Place the test file correctly:
- Follow the project's existing convention for test file location
- Use the project's naming convention (
.test.ts, .spec.js, _test.go, test_*.py, etc.)
E. Run the generated tests immediately to verify they pass.
- If tests fail, read the error output carefully
- Fix the test code (not the source code)
- Re-run until all tests pass
Run the existing test suite and analyze results.
A. Determine the test command:
- Check
package.json scripts.test for Node projects
- Use
pytest for Python projects
- Use
go test ./... for Go projects
- Use
cargo test for Rust projects
- Fall back to the detected framework's CLI
B. Run the tests:
- Execute the test command
- Capture full output including failures and errors
C. Analyze results:
- Report total passed, failed, skipped counts
- For each failure:
- Identify the failing test name and file
- Show the assertion that failed (expected vs actual)
- Read the relevant source code if needed
- Provide a specific diagnosis of why it failed
- Suggest a concrete fix (is it a test bug or a source bug?)
D. Present a summary:
Test Results: X passed, Y failed, Z skipped
Failures:
1. [test name] - [brief diagnosis]
Fix: [specific suggestion]
2. [test name] - [brief diagnosis]
Fix: [specific suggestion]
Suggest what to test when no arguments are given.
A. Check recent changes:
Working directory check: if your dispatch context specifies a working directory and pwd does not match it, prefix the git commands below with -C <that path> (e.g. git -C /path/to/worktree diff --name-only HEAD~5).
- Run
git diff --name-only HEAD~5 to find recently changed files
- Run
git diff --name-only --cached for staged files
- Filter to source files (exclude configs, docs, lockfiles)
B. Check test coverage gaps:
- Find source files that have no corresponding test file
- Prioritize files that were recently modified
C. Present suggestions:
Suggested files to test (based on recent changes and coverage gaps):
1. [file path] - modified recently, no test file exists
2. [file path] - modified recently, tests exist but may need updating
3. [file path] - no test coverage found
Run `/test <file path>` to generate tests for any of these.
Run `/test run` to run the existing test suite.
- MATCH EXISTING PATTERNS: Never impose a new test style. Always mirror what the project already does.
- READ BEFORE WRITING: Always read existing test files before generating new ones.
- VERIFY GENERATED TESTS: Always run generated tests. Untested test code is unreliable.
- DON'T MODIFY SOURCE CODE: If generated tests fail, fix the tests, not the source. If the source has a real bug, report it to the user.
- MOCK EXTERNAL DEPENDENCIES: Never let tests hit real APIs, databases, or file systems unless the project explicitly uses integration tests that way.
- ONE FILE AT A TIME: Generate tests for one source file per invocation. Keep scope manageable.
- USE PROJECT DEPENDENCIES: Only use test libraries already installed in the project. Do not add new dependencies without asking.
Before completing:
1---2name: test3description: Generate or run tests. Auto-detects test framework, generates comprehensive tests for source files, or runs existing test suites with failure analysis.4---56<objective>7Generate or run tests for the current project. This skill auto-detects the test framework in use, generates comprehensive tests for source files, or runs existing test suites and analyzes failures.89Accepts optional arguments:10- A file path: generate tests for that source file11- `run`: run the existing test suite and analyze results12- No arguments: suggest what to test based on recent changes13</objective>1415<context>16This skill handles test generation and execution across multiple languages and frameworks. It adapts to whatever testing conventions the project already uses rather than imposing new ones.17</context>1819<quick_start>2021<step_1_detect_framework>2223**Detect the test framework and conventions before doing anything else.**2425Check these sources in order:26271. **package.json** (Node/JS/TS projects):28 - `scripts.test` for the test command29 - `devDependencies` for jest, vitest, mocha, ava, tap, node:test, playwright, cypress30 - `jest` or `vitest` config keys31322. **Config files**:33 - `jest.config.*`, `vitest.config.*`, `.mocharc.*`, `ava.config.*`34 - `pytest.ini`, `pyproject.toml` (look for `[tool.pytest]`), `setup.cfg`35 - `go.mod` (Go projects use `go test` by default)36 - `Cargo.toml` (Rust projects use `cargo test`)37383. **Existing test files**:39 - Scan for `*.test.*`, `*.spec.*`, `*_test.*`, `test_*.*` files40 - Read 1-2 existing test files to understand patterns, imports, assertion style, and structure41 - Note the directory structure (co-located tests vs `__tests__/` vs `tests/` vs `test/`)42434. **Record your findings**:44 - Framework name and version45 - Test file naming convention46 - Test file location convention47 - Import/require style48 - Assertion style (expect, assert, chai, etc.)49 - Any custom utilities, fixtures, or helpers used5051</step_1_detect_framework>5253<step_2_handle_arguments>5455**Route based on the argument provided.**5657- **File path given** -> Go to `generate_tests`58- **"run" given** -> Go to `run_tests`59- **No arguments** -> Go to `suggest_tests`6061</step_2_handle_arguments>6263<generate_tests>6465**Generate tests for the specified source file.**6667**A. Read and analyze the source file:**68- Identify all exported/public functions, classes, methods, and types69- Understand each function's parameters, return types, and side effects70- Note error handling patterns (throws, returns null, returns Result, etc.)71- Identify dependencies that will need mocking7273**B. Read existing test files in the project (1-2 files minimum):**74- Match their import style exactly75- Match their describe/it or test block structure76- Match their assertion patterns77- Match their mock/stub approach78- Use the same test utilities and helpers7980**C. Generate tests covering:**81821. **Happy paths**: Normal expected inputs produce correct outputs832. **Edge cases**:84 - Empty inputs (empty string, empty array, null, undefined, zero)85 - Boundary values (min/max integers, very long strings)86 - Single element collections873. **Error handling**:88 - Invalid inputs that should throw or return errors89 - Missing required parameters90 - Type mismatches (if applicable)914. **Async behavior** (if the function is async):92 - Successful resolution93 - Rejection/error cases94 - Timeout scenarios (if relevant)955. **Dependencies**:96 - Mock external dependencies (APIs, databases, file system)97 - Verify correct interaction with dependencies (called with right args)9899**D. Place the test file correctly:**100- Follow the project's existing convention for test file location101- Use the project's naming convention (`.test.ts`, `.spec.js`, `_test.go`, `test_*.py`, etc.)102103**E. Run the generated tests immediately to verify they pass.**104- If tests fail, read the error output carefully105- Fix the test code (not the source code)106- Re-run until all tests pass107108</generate_tests>109110<run_tests>111112**Run the existing test suite and analyze results.**113114**A. Determine the test command:**115- Check `package.json` `scripts.test` for Node projects116- Use `pytest` for Python projects117- Use `go test ./...` for Go projects118- Use `cargo test` for Rust projects119- Fall back to the detected framework's CLI120121**B. Run the tests:**122- Execute the test command123- Capture full output including failures and errors124125**C. Analyze results:**126- Report total passed, failed, skipped counts127- For each failure:128 - Identify the failing test name and file129 - Show the assertion that failed (expected vs actual)130 - Read the relevant source code if needed131 - Provide a specific diagnosis of why it failed132 - Suggest a concrete fix (is it a test bug or a source bug?)133134**D. Present a summary:**135136```137Test Results: X passed, Y failed, Z skipped138139Failures:1401. [test name] - [brief diagnosis]141 Fix: [specific suggestion]1421432. [test name] - [brief diagnosis]144 Fix: [specific suggestion]145```146147</run_tests>148149<suggest_tests>150151**Suggest what to test when no arguments are given.**152153**A. Check recent changes:**154155> **Working directory check:** if your dispatch context specifies a working directory and `pwd` does not match it, prefix the git commands below with `-C <that path>` (e.g. `git -C /path/to/worktree diff --name-only HEAD~5`).156157- Run `git diff --name-only HEAD~5` to find recently changed files158- Run `git diff --name-only --cached` for staged files159- Filter to source files (exclude configs, docs, lockfiles)160161**B. Check test coverage gaps:**162- Find source files that have no corresponding test file163- Prioritize files that were recently modified164165**C. Present suggestions:**166167```168Suggested files to test (based on recent changes and coverage gaps):1691701. [file path] - modified recently, no test file exists1712. [file path] - modified recently, tests exist but may need updating1723. [file path] - no test coverage found173174Run `/test <file path>` to generate tests for any of these.175Run `/test run` to run the existing test suite.176```177178</suggest_tests>179180</quick_start>181182<critical_rules>1831841. **MATCH EXISTING PATTERNS**: Never impose a new test style. Always mirror what the project already does.1852. **READ BEFORE WRITING**: Always read existing test files before generating new ones.1863. **VERIFY GENERATED TESTS**: Always run generated tests. Untested test code is unreliable.1874. **DON'T MODIFY SOURCE CODE**: If generated tests fail, fix the tests, not the source. If the source has a real bug, report it to the user.1885. **MOCK EXTERNAL DEPENDENCIES**: Never let tests hit real APIs, databases, or file systems unless the project explicitly uses integration tests that way.1896. **ONE FILE AT A TIME**: Generate tests for one source file per invocation. Keep scope manageable.1907. **USE PROJECT DEPENDENCIES**: Only use test libraries already installed in the project. Do not add new dependencies without asking.191192</critical_rules>193194<success_criteria>195196Before completing:197- [ ] Test framework and conventions were detected correctly198- [ ] Generated tests match the project's existing test style199- [ ] All generated tests pass when run200- [ ] Tests cover happy paths, edge cases, and error handling201- [ ] Test file is placed in the correct location with the correct naming convention202- [ ] No source code was modified203204</success_criteria>