hunvreus Test
Input
- A behavior, bug, module, feature, failing test, or uncovered path to test.
- Use explicit input first; otherwise infer from context, recent edits, selected files, or branch.
- Safest default: identify public behavior and highest-risk paths before writing tests.
Workflow
- Define behavior. Identify the public interface and the behavior that matters to the user.
- Pick the first slice. Choose one narrow behavior that proves the path end to end.
- Write or repair tests. Prefer behavior-facing tests over implementation-detail tests.
- Use TDD when requested. Red: write one failing test. Green: write the smallest implementation that passes. Repeat by slice.
- Refactor when green. Simplify duplication, names, and module shape after tests pass.
- Validate. Run relevant tests, typecheck, lint, or build commands.
Output
- Behaviors covered
- Tests added, changed, or repaired
- Implementation changed, if any
- Validation run
- Remaining test gaps
Guardrails
- Do not write all tests before all implementation when using TDD.
- Prefer tests through public interfaces over private functions and internal mocks.
- Do not refactor while tests are red.
- Keep test scope proportional to behavior risk.