gen-ut

Generate Unit Tests

Input Conventions

Required inputs:

• Target class list (fully-qualified class names are recommended).

Optional inputs:

• Module name (limits Maven command scope).
• Test class list (for targeted execution only; does not limit in-place updates for related test classes).

Default completion level:

• Unless the user explicitly waives or lowers the target, requests such as "add tests" remain bound to R10-A completion criteria (including default coverage and quality gates).

Missing input handling:

• Note: this section only describes entry handling; final decisions follow R7/R10.
• Missing target classes: enter R10-INPUT_BLOCKED.
• Missing test classes: auto-discover with the TargetClassName + Test convention.
• No related test classes: create <TargetClassName>Test in the resolved module test source set.
• Cannot resolve <ResolvedTestModules>: enter R10-INPUT_BLOCKED and request additional module scope.

Terms

• <ResolvedTestClass>: one fully-qualified test class or a comma-separated list of test classes.
• <ResolvedTestFileSet>: editable file set (space-separated in shell commands), containing only related test files and required test resources.
• <ResolvedTestModules>: comma-separated Maven module list used by scoped verification commands.
• <ResolvedTargetClasses>: one fully-qualified production class or a comma-separated list of target classes from user input.
• Target-class coverage scope: for each target class, aggregate coverage for the target binary class and all binary classes whose names start with <targetBinaryName>$ (including member/anonymous/local classes).
• Related test classes: existing TargetClassName + Test classes resolvable within the same module's test scope.
• Assertion differences: distinguishable assertions in externally observable results or side effects.
• Necessity reason tag: fixed-format tag for retention reasons, using KEEP:<id>:<reason>, recorded in the "Implementation and Optimization" section of the delivery report.
• Baseline quality summary: one pre-edit diagnostic run that combines rule scanning, candidate summary, and coverage evidence for the current scope.
• Verification snapshot digest: content hash over <ResolvedTestFileSet> used to decide whether a previous green verification result is still reusable.
• Gate reuse state: persisted mapping from logical gate names (for example target-test, coverage, rule-scan) to the latest green digest for that gate.
• Latest green target-test digest: compatibility alias for the target-test entry in Gate reuse state.
• Consolidated hard-gate scan: one script execution that enforces R8, R14, and all file-content-based R15 rules while still reporting results per rule.

Module resolution order:

1. If the user explicitly provides modules, use them first.
2. Otherwise, resolve by searching upward for the nearest parent pom.xml from <ResolvedTestFileSet> paths.
3. Otherwise, resolve by searching upward for the nearest parent pom.xml from target class source paths.

Mandatory Constraints

• Norm levels: MUST (required), SHOULD (preferred), MAY (optional).

• Definition source principle: mandatory constraints are defined only in this R1-R15 section; other sections only provide term/workflow/command descriptions and must not add, override, or relax R1-R15.

• R1: MUST comply with AGENTS.md and CODE_OF_CONDUCT.md; rule interpretation should prioritize corresponding clauses and line-number evidence in CODE_OF_CONDUCT.md.

• R2: test types and naming

  • Non-parameterized scenarios MUST use JUnit @Test.
  • Data-driven scenarios MUST use JUnit @ParameterizedTest(name = "{0}") with @MethodSource + Arguments.
  • Parameterized test method signatures MUST use final String name as the first parameter.
  • Parameterized tests MUST NOT use Consumer (including java.util.function.Consumer and its generic forms) in method signatures or scenario-transport arguments.
  • Each parameterized test MUST provide at least 3 Arguments rows; fewer than 3 is a violation and MUST be converted to non-parameterized @Test.
  • Parameterized tests MUST NOT introduce new nested type declarations (member/local helper class / interface / enum / record) for scenario transport; use Arguments rows plus existing or JDK types instead.
  • MUST NOT use @RepeatedTest.
  • Test method naming MUST follow CODE_OF_CONDUCT.md: use the assert prefix; when a single test uniquely covers a production method, use assert<MethodName>.

• R3: change and execution scope

  • Edit scope MUST be limited to <ResolvedTestFileSet>.
  • Path scope MUST be limited to src/test/java and src/test/resources.
  • MUST NOT modify production code or generated directories (such as target/).
  • MUST NOT modify other test files to fix failures outside scope; if scope expansion is needed, MUST be explicitly approved by the user in the current turn.
  • MUST NOT use destructive git operations (for example, git reset --hard, git checkout --).

• R4: branch list and mapping

  • Before coding, MUST enumerate branches/paths of target public methods and build branch-to-test mappings.
  • Branch mapping scope MUST exclude Lombok-generated methods without custom logic.
  • By default, one branch/path maps to one test method.
  • Whether to keep additional tests on the same branch is determined by R13.

• R5: test granularity

  • Each test method MUST cover only one scenario.
  • Each test method MUST call the target public method at most once; additional assertions are allowed in the same scenario.
  • For parameterized tests, each Arguments row MUST represent one independent scenario and one branch/path mapping unit for R4.
  • For parameterized tests, Arguments row count MUST be greater than or equal to 3.
  • Tests MUST exercise behavior through public methods only.
  • Coverage-relevant invocations of target public methods MUST appear in test method bodies together with assertions for the externally observable result of that invocation.
  • Helper methods and @MethodSource providers MUST NOT invoke target public methods merely to warm caches, precompute coverage, or otherwise execute target behavior without assertions in the same test method body.
  • Public production methods with business logic MUST be covered with dedicated test methods.
  • For interface targets, only default public methods are required test targets by default, and non-default public methods MUST NOT be tested unless the user explicitly requests them in the current turn.
  • Dedicated test targets MUST follow the R4 branch-mapping exclusion scope.

• R6: SPI, Mock, and reflection

  • For interface default methods, this rule overrides SPI instantiation requirements in R6: tests MUST use Mockito CALLS_REAL_METHODS to invoke real default implementations, and this path does not require SPI-bypass justification.
  • If the class under test can be obtained via SPI, MUST instantiate by default with TypedSPILoader/OrderedSPILoader (or database-specific loaders), and MUST keep the resolved instance as a test-class-level field (global variable) by default.
  • SPI metadata accessor methods TypedSPI#getType, OrderedSPI#getOrder, and getTypeClass are default no-test-required targets.
  • For these accessors, tests MUST NOT be added by default; they are allowed only when the user explicitly requests tests for them in the current turn.
  • If such tests are added without explicit request, they MUST be removed before completion.
  • If not instantiated via SPI, MUST record the reason before implementation.
  • Test dependencies SHOULD use Mockito mocks by default.
  • Reflection access MUST use Plugins.getMemberAccessor(), and field access only.

• R7: related test class strategy

  • If related test classes already exist, MUST update in place and fill missing coverage first.
  • If no related test class exists, MUST create <TargetClassName>Test.
  • If the user explicitly provides a test class list, it is only used as execution filtering input and MUST NOT replace the "in-place update of related test classes" strategy.
  • Deletion/merge of coverage-equivalent tests is determined by R13.

• R8: parameterized optimization (enabled by default)

  • MUST run pre-implementation candidate analysis and output an R8-CANDIDATES record (target public method, candidate count, decision, and evidence).
  • MUST report the mergeable method set and merge candidate count.
  • Candidates meeting all conditions below are considered "high-fit for parameterization":
    • A. target public method and branch skeleton are consistent;
    • B. scenario differences mainly come from input data;
    • C. assertion skeleton is consistent, or only declared assertion differences exist;
    • D. parameter sample count is at least 3;
    • E. parameterized test body does not require dispatch logic via switch.
  • "Declared assertion differences" means differences explicitly recorded in the delivery report.
  • If a candidate requires switch in a @ParameterizedTest body to distinguish argument rows, it is not high-fit and MUST NOT be refactored to parameterized form.
  • High-fit candidates MUST be refactored directly to parameterized form.
  • For high-fit candidates, a "do not recommend refactor" conclusion is allowed only when refactoring causes significant readability/diagnosability regression, and the exception MUST include a Necessity reason tag with concrete evidence.
  • Parameter construction MUST use Arguments + @MethodSource.
  • MUST provide either a "recommend refactor" or "do not recommend refactor" conclusion with reasons for each candidate; when no candidates exist, MUST output "no candidates + decision reason".
  • If high-fit candidates exist but neither p

---

Content truncated.