Unit Test Generation Workflow
Generate unit tests for given function(s) in a codebase. Work in phases. Output only the requested artifacts.
Inputs Required
- fileOrFolder: The file or folder path to generate unit tests for
- functionToTest (optional): Specific function to test
- language (optional): Override language detection
Procedure
Phase 1 - Detect Language and Environment
- Identify programming language from file extension
- Detect testing framework used in the codebase by analyzing dependencies file and existing test files
- If multiple frameworks detected, choose the one used for unit tests. Prefer the one already present in existing tests file close to fileOrFolder location
Phase 2 - Locate Placement
- Search for existing tests covering the target module. Decide if test should be appended to existing file or if new file should be created
- If creating new file, analyze existing test files to correctly use same naming convention
- If appending, set up test cases similarly to existing tests. If creating new file, analyze existing test files to correctly set up the testing framework
Phase 3 - Analyze Code Under Test
- Parse signatures, inputs, outputs, side effects, expected and exceptional paths, async/await, throw or reverts, edge cases
- Map branches and guards. Identify boundary values and invariants. Mark non-determinism sources (time, RNG, I/O)
Phase 4 - Design Cases
- Create a minimal set for branch coverage. Include happy paths, boundary/edge cases, and failure modes
- Add security-focused cases: invalid/tainted inputs, injection payloads, path traversal, overflow/underflow, encoding pitfalls, fuzz/property checks for pure functions
- Define mocking/stubbing plan attempting to follow existing patterns to never hit real network, database, filesystem, clock, or randomness
Phase 5 - Emit Tests
- Produce tests consistent with the framework's style and project imports. Keep small, pure helpers. No hidden side effects
- Add as many tests as seem appropriate to cover all path/security/cases/edge cases
- Ensure deterministic execution
Phase 6 - Validate Statically
- Self-check imports, assertion usage, compilation or type errors and lints. Avoid duplicate tests
- Output estimated coverage from new tests
Phase 7 - Run Tests
- Run tests individually following test framework instructions and make sure they pass
Language Specifics
- TypeScript/JavaScript: Respect tsconfig/moduleResolution. Detect framework in package.json. Use fake timers instead of real time
- Rust: Use #[cfg(test)] modules, proptest when property tests enabled
Constraints
- No original code file writes or schema changes
- Use meaningful test case names
- Prefer pure helpers and table-driven tests
- Analyze only within the given code. Do not invent missing context or external APIs
Skill Chaining
After Phase 7 (Run Tests)
| Chain To |
Condition |
| property-based-testing |
Pure functions, roundtrip patterns detected |
| repo-hygiene |
Always (terminal) |
Chains From
| Source |
When |
| suggest-tests |
HIGH risk functions identified |
| tdd |
Comprehensive generation needed |
Testing Pipeline Position
unit-test-workflow is step 3 in the testing pipeline:
tdd → suggest-tests → unit-test-workflow → property-based-testing → repo-hygiene
↑
(you are here)
Terminal Chain
After all tests pass: repo-hygiene (clean temporary test files)
1---2name: unit-test-workflow3description: Guided multi-phase workflow for designing and generating comprehensive unit tests4---5
6# Unit Test Generation Workflow
7
8Generate unit tests for given function(s) in a codebase. Work in phases. Output only the requested artifacts.
9
10## Inputs Required
11- fileOrFolder: The file or folder path to generate unit tests for
12- functionToTest (optional): Specific function to test
13- language (optional): Override language detection
14
15## Procedure
16
17### Phase 1 - Detect Language and Environment
181. Identify programming language from file extension
192. Detect testing framework used in the codebase by analyzing dependencies file and existing test files
203. If multiple frameworks detected, choose the one used for unit tests. Prefer the one already present in existing tests file close to fileOrFolder location
21
22### Phase 2 - Locate Placement
234. Search for existing tests covering the target module. Decide if test should be appended to existing file or if new file should be created
245. If creating new file, analyze existing test files to correctly use same naming convention
256. If appending, set up test cases similarly to existing tests. If creating new file, analyze existing test files to correctly set up the testing framework
26
27### Phase 3 - Analyze Code Under Test
287. Parse signatures, inputs, outputs, side effects, expected and exceptional paths, async/await, throw or reverts, edge cases
298. Map branches and guards. Identify boundary values and invariants. Mark non-determinism sources (time, RNG, I/O)
30
31### Phase 4 - Design Cases
329. Create a minimal set for branch coverage. Include happy paths, boundary/edge cases, and failure modes
3310. Add security-focused cases: invalid/tainted inputs, injection payloads, path traversal, overflow/underflow, encoding pitfalls, fuzz/property checks for pure functions
3411. Define mocking/stubbing plan attempting to follow existing patterns to never hit real network, database, filesystem, clock, or randomness
35
36### Phase 5 - Emit Tests
3712. Produce tests consistent with the framework's style and project imports. Keep small, pure helpers. No hidden side effects
3813. Add as many tests as seem appropriate to cover all path/security/cases/edge cases
3914. Ensure deterministic execution
40
41### Phase 6 - Validate Statically
4215. Self-check imports, assertion usage, compilation or type errors and lints. Avoid duplicate tests
4316. Output estimated coverage from new tests
44
45### Phase 7 - Run Tests
4617. Run tests individually following test framework instructions and make sure they pass
47
48## Language Specifics
49- **TypeScript/JavaScript**: Respect tsconfig/moduleResolution. Detect framework in package.json. Use fake timers instead of real time
50- **Rust**: Use #[cfg(test)] modules, proptest when property tests enabled
51
52## Constraints
53- No original code file writes or schema changes
54- Use meaningful test case names
55- Prefer pure helpers and table-driven tests
56- Analyze only within the given code. Do not invent missing context or external APIs
57
58## Skill Chaining
59
60### After Phase 7 (Run Tests)
61
62| Chain To | Condition |
63|----------|-----------|
64| property-based-testing | Pure functions, roundtrip patterns detected |
65| repo-hygiene | Always (terminal) |
66
67### Chains From
68
69| Source | When |
70|--------|------|
71| suggest-tests | HIGH risk functions identified |
72| tdd | Comprehensive generation needed |
73
74### Testing Pipeline Position
75
76unit-test-workflow is step 3 in the testing pipeline:
77
78```
79tdd → suggest-tests → unit-test-workflow → property-based-testing → repo-hygiene
80 ↑
81 (you are here)
82```
83
84### Terminal Chain
85
86After all tests pass: **repo-hygiene** (clean temporary test files)