/test

name: test
description: Generate or run tests. Auto-detects test framework, generates comprehensive tests for source files, or runs existing test suites with failure analysis.

<objective> Generate 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.

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

</objective>

<context> This 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. </context>

<quick_start>

<step_1_detect_framework>

**Detect the test framework and conventions before doing anything else.**

Check these sources in order:

1. **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

2. **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`)

3. **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/`)

4. **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

</step_1_detect_framework>

<step_2_handle_arguments>

**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`

</step_2_handle_arguments>

<generate_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:**

1. **Happy paths**: Normal expected inputs produce correct outputs 2. **Edge cases**:

• Empty inputs (empty string, empty array, null, undefined, zero)
• Boundary values (min/max integers, very long strings)
• Single element collections

3. **Error handling**:

• Invalid inputs that should throw or return errors
• Missing required parameters
• Type mismatches (if applicable)

4. **Async behavior** (if the function is async):

• Successful resolution
• Rejection/error cases
• Timeout scenarios (if relevant)

5. **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

</generate_tests>

<run_tests>

**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]

</run_tests>

<suggest_tests>

**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 o