Unit Test Master v4.0 — Context-First Hybrid Mode

> Architecture: Context-First + Hybrid Mode.
> Context-First: Before any agent dispatch or fix, deeply understand the tested code's business context and data structures. Inject this understanding as a "context anchor" into all subsequent phases.
> Hybrid Mode: Orchestrator handles routing, complexity assessment, and decisions; simple fixes are done inline in the main dialog (Inline Fix), complex tasks are delegated to sub-agents with independent context.
> Core principle: The biggest bottleneck for AI writing tests is not code generation capability, but understanding depth of the tested code.

Trigger: When user requests writing unit tests, coverage, fixing test errors, or scanning all failed cases.

Iron Laws: Test Isolation (highest priority, violation = breach)

> Tests are "clients" of tested code. Senior engineers treat tested code as an immutable black box — tests adapt to code, not code to tests.

1. Never modify non-test code: Only create or modify files in test directories (e.g., src/test/, __tests__/, *_test.go). Source code, config files, dependency management files must not be touched.
   - If tested code is hard to test (static methods, hardcoded deps, final classes), report in DfT assessment and stop for user decision — never "helpfully refactor" tested code
   - If tested method signature changed causing test compile failure, only modify test code to adapt to new signature
2. Never introduce new dependencies: Only use project-declared dependencies. Introducing new deps is an architecture decision, not a test engineer's job.
   - If a utility class is needed but absent, implement equivalent functionality using existing dependencies
   - If a new dependency is truly required, report to user and wait for confirmation
3. Never modify test infrastructure: Test base classes, shared config files, etc. must not be changed without explicit user authorization

Core Writing Strategy (always in effect)

• Coverage-oriented: Only write cases for uncovered lines, not extra path combinations
• Minimal case set: Choose paths that penetrate the most uncovered lines; same coverage keeps only one case
• Parameterized tests: Prefer parameterized tests to cover multiple branches with one data set
• Mock external deps: Use mock framework to simulate external calls, bypass complex prerequisites
• Test naming: should_{expected_behavior}_when_{condition}, never Chinese names
• Test structure: Strict Given-When-Then three-section format

Intent Recognition Routing

Test-related request received
    |
    |-- TDD / Spec-First → references/path-tdd.md
    |       Trigger words: "TDD", "test first", "先写测试", "spec-driven test", "BDD", "验证需求"
    |
    |-- Autopilot inspection -> references/path-inspection.md (Phase 0A)
    |       Trigger words: "start test inspection", "run tests then fix", "auto-fix all failures"
    |
    |-- Manual inspection -> references/path-inspection.md (Phase 0)
    |       Trigger words: "scan failed cases", "full inspection", "see which tests failed"
    |
    |-- Resume from checkpoint -> references/path-inspection.md (Phase 0B)
    |       Trigger words: "continue fixing tests", "resume"
    |
    |-- Write new test -> references/path-new-test.md (Phases 1-3)
    |
    |-- Fix existing test -> references/path-fix-test.md (Phases 1-2)

Fix Path Complexity Routing

Complexity assessment:
    |-- Green: <=2 errors, type clear, single file -> Inline Fix (main dialog)
    |-- Yellow: >=3 errors or framework/mock/multi-file -> Delegated Fix (sub-agent)
    |-- Red: >=3 test classes failing -> Batch Fix (Phase 0 inspection)

References

Quality Self-Check (short version)

After any test action, verify:
1. Isolation: Did I touch only test files? No source/config/dependency changes?
2. Intent preservation: Does the test still verify the original business behavior? No assertion weakening?
3. Experience capture: Should new patterns be recorded in .notes/ assets?

Bound Knowledge Assets

Sub-Agent Prompt Templates

Core Process Assets