gen-tests

Generate Tests for OhMyCode

Generate project-convention-compliant tests for a given module or file.

This skill is part of the OhMyCode development closed-loop:

编码 ──→ /gen-tests ──→ /run-tests ──→ 分析失败 ──→ 修代码 ──╮
 ↑                                                            │
 ╰────────────────────────────────────────────────────────────╯

After generating tests, always proceed to /run-tests to verify them.

When to Use

• User says "gen tests", "write tests", "add tests for …"
• User provides a module name or file path (e.g., ohmycode/tools/bash.py, core/loop)
• As part of the development loop: just finished writing/modifying source code and need tests

Input

$ARGUMENTS — module name or file path to test (e.g., ohmycode/tools/bash.py, core/loop, providers/anthropic).

If $ARGUMENTS is empty, ask the user which module to generate tests for.

Step 1 — Resolve Target

Map the argument to a source file path:

Argument form	Resolved source path
ohmycode/tools/bash.py	use as-is
tools/bash	ohmycode/tools/bash.py
core/loop	ohmycode/core/loop.py
providers/openai	ohmycode/providers/openai.py
config	ohmycode/config/config.py

Read the resolved source file. Identify:

• Public classes / functions (skip _private unless critical)
• Async vs sync interfaces
• External dependencies (API calls, file I/O, subprocesses)
• Branch paths (if/else, error returns, edge cases)

Step 2 — Read Existing Test Patterns

1. Read tests/conftest.py to learn available fixtures:

   • MockProvider — fake LLM that yields configurable responses, use for anything touching providers
   • mock_provider — fixture returning a default MockProvider()
   • mock_config — minimal config dict
   • tmp_dir — alias for tmp_path, use for file-based tests

2. Check for existing test file at the mirror path (see Step 4 path rule). If it exists, read it to understand current coverage and style — extend rather than overwrite.