---
name: test-gen
description: Generate unit or integration tests for a target file or function. Picks the project's existing test framework, mirrors the surrounding test style, and covers the happy path plus the edge cases the implementation guards against. Trigger keywords — write tests, generate tests, add coverage, test this function, missing tests, what cases am I missing.
when_to_use: When the user has just written, modified, or pointed at code that lacks coverage and asks for tests. Especially useful when the test framework + style are already established in the project — this skill mirrors the existing tests rather than imposing a generic template.
arguments:
  - name: target
    description: Path to the file (or function within a file) that needs tests. Optional — defaults to the file the user is currently discussing.
vendor: qodo
version: 1.0.0
---

# Test generation

Generate tests that match how the project already writes them.

## Before writing anything

Read these in order so the generated tests fit:

1. **The target file.** Identify the public surface, the failure modes the implementation explicitly guards against, and any nontrivial invariants.
2. **The nearest existing test file** in the project (same directory, sibling `tests/` directory, or `__tests__/`). Mirror its imports, naming convention, fixture pattern, assertion style. If the project uses `describe/it`, don't switch to `test()`. If the project uses `assert`, don't switch to `expect`.
3. **The project's test runner config** (`vitest.config`, `jest.config`, `package.json` scripts). Confirm the runner before assuming.

If no existing tests are present, fall back to the framework the package.json declares, in this priority: `vitest` → `jest` → `mocha` → `node:test`. Output the chosen runner in a one-line preamble so the user can redirect.

## What to cover

For each public function or class method exposed by the target:

- **Happy path**: the documented contract, single test.
- **Boundary cases**: empty input, single-element input, the largest input the implementation explicitly handles. Skip unbounded "what if N=10^9" speculation.
- **Documented error paths**: each `throw`, each `return null/undefined`, each `if (!X)` early return. One test per branch.
- **Side effects**: if the function writes to disk, the network, or shared state, assert the effect — not just the return value.

## What NOT to do

- Don't write tests for trivial getters/setters, pure pass-throughs, or generated code.
- Don't mock the system under test. Mock its collaborators.
- Don't assert on log output unless the log is part of the documented contract.
- Don't add `test.todo` placeholders; either write the test or omit it.
- Don't pad the suite. A focused 6-test file beats a 30-test file padded with permutations.

## Output

Write the test file. If the project uses a `tests/` mirror tree, place it there. If it uses sibling `*.test.ts` files, place it next to the target. Match the existing convention — don't introduce a new layout.

After writing, run the test command (if known) and report the result. If any test fails, fix the test (not the implementation) unless you've found a genuine bug — in which case, flag it explicitly.