Build Tests Mode

Plan and build tests for the current feature branch.

Additional test focus

"$ARGUMENTS"

If provided, the above gives optional extra constraints or focus areas for test planning. By default, the skill plans and builds tests for all current branch changes without needing any arguments.

Process

Use a subagent to carry out the following 2 phases sequentially:

Phase 1: Test Planning

• Read the plan file (plan-*.md) in the current working directory to understand what was built and why
• Read the implementation code — explore all files changed on this branch
• Run git diff origin/main...HEAD to see all changes
• Produce a test plan covering:
• What modules/functions/classes need testing
• What behaviors and edge cases to cover
• What integration points to verify
• What NOT to mock (and why)
• What testing approach for each component (unit vs integration vs E2E)

Phase 2: Test Building

Write tests following the test plan from Phase 1. Run all tests and fix any failures before finishing.

#### Mocking Rules — CRITICAL

Unit tests — mocks are fine:

• Mocks are the standard way to isolate the unit under test. Use them to stub dependencies so you can test one module in isolation.
• NEVER mock the code under test itself — that defeats the purpose.
• Keep mocks focused: if you need more than 2-3 mocks in a single test, the design may need rethinking.

Integration tests — NO mocks:

• Wire real components together. The whole point is verifying that real modules work as a system.
• Use real instances of data structures, models, and value objects.
• Invest in proper test fixtures and factories instead of mocking to avoid setup.
• The ONLY acceptable exceptions: external services (APIs, network calls), time/randomness, slow/flaky third-party libs.

General rules:

• Integration tests are the bulk of the test suite — they catch the bugs that matter most.
• Unit tests complement them for fast feedback on isolated logic.
• E2E tests: few but critical — verify complete user-facing workflows.