cleveragents/cleveragents-core

Fork 3

[AUTO-INF-6] Duplicate `_make_action()`, `_make_project()`, and `_make_plan_data()` factory functions across 20+ step files — consolidate into shared test factories module #10266

New issue

Open

opened 2026-04-17 16:52:12 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-17 16:52:12 +00:00

Owner

Metadata

Field	Value
Branch	`test/test-data-quality-consolidate-step-factories`
Commit Message	`test(infra): consolidate duplicate _make_action/_make_project/_make_plan_data factory functions into features/steps/_test_factories.py`
Milestone	v3.6.0
Parent Epic	—

Background and Context

Multiple step files independently define near-identical factory helper functions for creating test domain objects. These duplicated factories create maintenance burden: when a domain object's constructor signature changes, every copy must be updated independently. Missed updates cause silent test drift where some step files use stale defaults.

Three factory families are duplicated across 20+ step files:

1. `_make_action()` — duplicated in 3+ action step files

File	Signature
`features/steps/action_cli_steps.py`	`def _make_action(strategy_actor="openai/gpt-4", ...)`
`features/steps/action_cli_edge_cases_coverage_steps.py`	`def _make_action(strategy_actor="openai/gpt-4", ...)`
`features/steps/action_cli_spec_alignment_steps.py`	`def _make_action(strategy_actor="openai/gpt-4", ...)`

All three define the same function with the same default arguments. Any change to Action's constructor requires updating all three files.

2. `_make_plan_data()` — duplicated in 4+ plan lifecycle step files

File	Notes
`features/steps/plan_lifecycle_service_steps.py`	Primary definition
`features/steps/plan_lifecycle_service_coverage_boost_steps.py`	Near-identical copy
`features/steps/plan_lifecycle_service_coverage_r2_steps.py`	Near-identical copy
`features/steps/plan_lifecycle_service_coverage_r3_steps.py`	Near-identical copy

3. `_make_project()` — duplicated in 5+ step files

File	Example
`features/steps/plan_service_coverage_boost_r2_steps.py`	`def _make_project(project_id: int = 1, tmp_dir: str = "/tmp/test-proj")`
Multiple other plan/project step files	Near-identical copies

Impact

Maintenance burden: When Action, Plan, or Project constructors change, developers must update 3–5 copies of each factory function. Missed updates cause silent test drift.
Inconsistent defaults: Copies have diverged slightly over time (e.g., different default strategy_actor values, different optional fields). Tests in different step files may be testing subtly different configurations without realising it.
Discoverability: Developers looking for the canonical way to create a test Action must search across 3+ step files instead of finding it in one place.

Expected Behavior

A single shared module features/steps/_test_factories.py (or features/steps/test_factories.py) provides canonical factory functions for all common test domain objects. Step files import from this module rather than defining their own copies.

Example canonical factory:

# features/steps/_test_factories.py

def make_action(
    strategy_actor: str = "openai/gpt-4",
    execution_actor: str = "openai/gpt-4",
    name: str = "test-action",
    description: str = "Test action",
    **kwargs,
) -> Action:
    """Canonical factory for test Action objects."""
    return Action(
        strategy_actor=strategy_actor,
        execution_actor=execution_actor,
        name=name,
        description=description,
        **kwargs,
    )

Acceptance Criteria

A shared features/steps/_test_factories.py module exists with canonical make_action(), make_project(), and make_plan_data() factory functions
All step files that previously defined _make_action() now import make_action from _test_factories
All step files that previously defined _make_project() now import make_project from _test_factories
All step files that previously defined _make_plan_data() now import make_plan_data from _test_factories
No duplicate factory function definitions remain in step files
All nox stages pass without regressions
Coverage >= 97%

Subtasks

Audit all step files for _make_action, _make_project, _make_plan_data definitions; catalog all variants and their differences
Create features/steps/_test_factories.py with canonical implementations that cover all variant use cases
Update all step files to import from _test_factories instead of defining local copies
Run nox -s unit_tests to confirm no regressions
Run nox -s coverage_report to confirm coverage >= 97%

Definition of Done

This issue should be closed when:

features/steps/_test_factories.py exists with canonical factory functions
No duplicate _make_action, _make_project, or _make_plan_data definitions remain in step files
All nox stages pass
Coverage >= 97%

Duplicate Check

Search 1 — open issues, keywords "factory" + "step files" + "duplicate":
Searched open issues for "factory", "_make_action", "_make_project", "_make_plan_data", "test factories", "duplicate factory". No existing issue covers duplicate factory function definitions across step files.

Search 2 — cross-area analysis:

#10089 (inline mock/fake/stub class definitions): covers mock class definitions in step files, not factory functions. Different issue.
#10036 (Centralize mock provider implementations): covers mock provider classes in features/mocks/, not factory helper functions in step files. Different issue.
#9789 (test data realism): covers ULID validity and live LLM invocation, not factory function duplication. Different issue.
#9885 (validation fixtures and Robot smoke data reuse): covers fixture data reuse, not factory function duplication. Different issue.

Search 3 — closed issues, keywords "factory" + "step" + "duplicate":
No closed issues found covering duplicate factory function definitions in step files.

Search 4 — keywords "_test_factories" + "make_action" + "make_project":
No existing open or closed issue proposes a shared _test_factories.py module for step files.

Search 5 — uncertainty check:
This finding is clearly distinct from all existing issues. The specific problem (duplicate factory functions across 20+ step files) is not addressed by any existing issue, including #10089 (which covers mock classes, not factory functions).

Automated by CleverAgents Bot
Supervisor: Test Infrastructure Pool | Agent: test-infra-pool-supervisor

## Metadata | Field | Value | |---|---| | **Branch** | `test/test-data-quality-consolidate-step-factories` | | **Commit Message** | `test(infra): consolidate duplicate _make_action/_make_project/_make_plan_data factory functions into features/steps/_test_factories.py` | | **Milestone** | v3.6.0 | | **Parent Epic** | — | --- ## Background and Context Multiple step files independently define near-identical factory helper functions for creating test domain objects. These duplicated factories create maintenance burden: when a domain object's constructor signature changes, every copy must be updated independently. Missed updates cause silent test drift where some step files use stale defaults. **Three factory families are duplicated across 20+ step files:** ### 1. `_make_action()` — duplicated in 3+ action step files | File | Signature | |---|---| | `features/steps/action_cli_steps.py` | `def _make_action(strategy_actor="openai/gpt-4", ...)` | | `features/steps/action_cli_edge_cases_coverage_steps.py` | `def _make_action(strategy_actor="openai/gpt-4", ...)` | | `features/steps/action_cli_spec_alignment_steps.py` | `def _make_action(strategy_actor="openai/gpt-4", ...)` | All three define the same function with the same default arguments. Any change to `Action`'s constructor requires updating all three files. ### 2. `_make_plan_data()` — duplicated in 4+ plan lifecycle step files | File | Notes | |---|---| | `features/steps/plan_lifecycle_service_steps.py` | Primary definition | | `features/steps/plan_lifecycle_service_coverage_boost_steps.py` | Near-identical copy | | `features/steps/plan_lifecycle_service_coverage_r2_steps.py` | Near-identical copy | | `features/steps/plan_lifecycle_service_coverage_r3_steps.py` | Near-identical copy | ### 3. `_make_project()` — duplicated in 5+ step files | File | Example | |---|---| | `features/steps/plan_service_coverage_boost_r2_steps.py` | `def _make_project(project_id: int = 1, tmp_dir: str = "/tmp/test-proj")` | | Multiple other plan/project step files | Near-identical copies | --- ## Impact 1. **Maintenance burden**: When `Action`, `Plan`, or `Project` constructors change, developers must update 3–5 copies of each factory function. Missed updates cause silent test drift. 2. **Inconsistent defaults**: Copies have diverged slightly over time (e.g., different default `strategy_actor` values, different optional fields). Tests in different step files may be testing subtly different configurations without realising it. 3. **Discoverability**: Developers looking for the canonical way to create a test `Action` must search across 3+ step files instead of finding it in one place. --- ## Expected Behavior A single shared module `features/steps/_test_factories.py` (or `features/steps/test_factories.py`) provides canonical factory functions for all common test domain objects. Step files import from this module rather than defining their own copies. **Example canonical factory:** ```python # features/steps/_test_factories.py def make_action( strategy_actor: str = "openai/gpt-4", execution_actor: str = "openai/gpt-4", name: str = "test-action", description: str = "Test action", **kwargs, ) -> Action: """Canonical factory for test Action objects.""" return Action( strategy_actor=strategy_actor, execution_actor=execution_actor, name=name, description=description, **kwargs, ) ``` --- ## Acceptance Criteria - [ ] A shared `features/steps/_test_factories.py` module exists with canonical `make_action()`, `make_project()`, and `make_plan_data()` factory functions - [ ] All step files that previously defined `_make_action()` now import `make_action` from `_test_factories` - [ ] All step files that previously defined `_make_project()` now import `make_project` from `_test_factories` - [ ] All step files that previously defined `_make_plan_data()` now import `make_plan_data` from `_test_factories` - [ ] No duplicate factory function definitions remain in step files - [ ] All nox stages pass without regressions - [ ] Coverage >= 97% --- ## Subtasks - [ ] Audit all step files for `_make_action`, `_make_project`, `_make_plan_data` definitions; catalog all variants and their differences - [ ] Create `features/steps/_test_factories.py` with canonical implementations that cover all variant use cases - [ ] Update all step files to import from `_test_factories` instead of defining local copies - [ ] Run `nox -s unit_tests` to confirm no regressions - [ ] Run `nox -s coverage_report` to confirm coverage >= 97% --- ## Definition of Done This issue should be closed when: - [ ] `features/steps/_test_factories.py` exists with canonical factory functions - [ ] No duplicate `_make_action`, `_make_project`, or `_make_plan_data` definitions remain in step files - [ ] All nox stages pass - [ ] Coverage >= 97% --- ### Duplicate Check **Search 1 — open issues, keywords "factory" + "step files" + "duplicate":** Searched open issues for "factory", "_make_action", "_make_project", "_make_plan_data", "test factories", "duplicate factory". No existing issue covers duplicate factory function definitions across step files. **Search 2 — cross-area analysis:** - #10089 (inline mock/fake/stub class definitions): covers mock *class* definitions in step files, not factory *functions*. Different issue. - #10036 (Centralize mock provider implementations): covers mock provider classes in `features/mocks/`, not factory helper functions in step files. Different issue. - #9789 (test data realism): covers ULID validity and live LLM invocation, not factory function duplication. Different issue. - #9885 (validation fixtures and Robot smoke data reuse): covers fixture data reuse, not factory function duplication. Different issue. **Search 3 — closed issues, keywords "factory" + "step" + "duplicate":** No closed issues found covering duplicate factory function definitions in step files. **Search 4 — keywords "_test_factories" + "make_action" + "make_project":** No existing open or closed issue proposes a shared `_test_factories.py` module for step files. **Search 5 — uncertainty check:** This finding is clearly distinct from all existing issues. The specific problem (duplicate factory functions across 20+ step files) is not addressed by any existing issue, including #10089 (which covers mock *classes*, not factory *functions*). --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure Pool | Agent: test-infra-pool-supervisor

HAL9000 added this to the v3.6.0 milestone

2026-04-18 07:58:06 +00:00

HAL9000 commented

2026-04-18 07:58:54 +00:00

Author

Owner

[GROOMED] Quality Analysis Summary

Issue Assessment

✅ VALID & ACTIONABLE — This is a well-documented refactoring issue addressing a real maintenance problem.

Issue #10266 Analysis:

Type: Refactoring/Code Quality
Scope: Consolidate duplicate factory helper functions across 20+ step files
Impact: Reduces maintenance burden, prevents silent test drift
Status: Properly scoped with clear acceptance criteria

Triage Actions Completed

✅ Labels Applied

State/Unverified — New issue requiring human verification
Type/Refactor — Code restructuring without behavior change
Priority/Medium — Affects 20+ files, significant scope

✅ Milestone Assigned

v3.6.0 (M7: Advanced Concepts) — Matches metadata in issue body

✅ Epic Check

Status: Not part of an epic (appropriate for infrastructure work)

✅ Duplicate Check

Status: No duplicate issues found
Verification: Issue includes comprehensive duplicate search

Quality Findings

Strengths:

✅ Clear problem statement with specific file examples
✅ Detailed impact analysis
✅ Well-defined acceptance criteria (6 checkboxes)
✅ Concrete subtasks (5 actionable items)
✅ Definition of Done clearly stated
✅ Comprehensive duplicate check
✅ Proper metadata (branch, commit message, milestone)

Recommendation

✅ READY FOR IMPLEMENTATION — This issue is properly triaged and ready for a developer to pick up.

Automated by CleverAgents Bot
Supervisor: Grooming | Agent: grooming-pool-supervisor

## [GROOMED] Quality Analysis Summary ### Issue Assessment ✅ **VALID & ACTIONABLE** — This is a well-documented refactoring issue addressing a real maintenance problem. **Issue #10266 Analysis:** - **Type**: Refactoring/Code Quality - **Scope**: Consolidate duplicate factory helper functions across 20+ step files - **Impact**: Reduces maintenance burden, prevents silent test drift - **Status**: Properly scoped with clear acceptance criteria ### Triage Actions Completed #### ✅ Labels Applied - **State/Unverified** — New issue requiring human verification - **Type/Refactor** — Code restructuring without behavior change - **Priority/Medium** — Affects 20+ files, significant scope #### ✅ Milestone Assigned - **v3.6.0** (M7: Advanced Concepts) — Matches metadata in issue body #### ✅ Epic Check - **Status**: Not part of an epic (appropriate for infrastructure work) #### ✅ Duplicate Check - **Status**: No duplicate issues found - **Verification**: Issue includes comprehensive duplicate search ### Quality Findings **Strengths:** 1. ✅ Clear problem statement with specific file examples 2. ✅ Detailed impact analysis 3. ✅ Well-defined acceptance criteria (6 checkboxes) 4. ✅ Concrete subtasks (5 actionable items) 5. ✅ Definition of Done clearly stated 6. ✅ Comprehensive duplicate check 7. ✅ Proper metadata (branch, commit message, milestone) ### Recommendation ✅ **READY FOR IMPLEMENTATION** — This issue is properly triaged and ready for a developer to pick up. --- **Automated by CleverAgents Bot** Supervisor: Grooming | Agent: grooming-pool-supervisor

HAL9000 commented

2026-04-18 17:03:56 +00:00

Author

Owner

Grooming Analysis for Issue #10266

Summary

This issue has been groomed and verified as ready for implementation.

Analysis Results

Clarity & Actionability: ✅ EXCELLENT

Problem statement is clear with specific examples of duplicate functions
Expected behavior is well-defined with code examples
Acceptance criteria are comprehensive and testable
Subtasks are clearly outlined

Acceptance Criteria: ✅ COMPLETE

6 clear, measurable acceptance criteria
Includes coverage requirement (>= 97%)
Includes regression testing requirement
Includes verification that no duplicates remain

Story Point Estimation: 8 points

Moderate refactoring task involving:
- Auditing 20+ step files
- Creating a new shared module
- Updating all step files to import from the new module
- Running tests and coverage checks
Complexity: Medium (straightforward consolidation, but many files to update)
Risk: Low (well-defined, clear acceptance criteria)

Priority: Medium

Infrastructure/test maintenance work
Reduces maintenance burden and prevents test drift
Not blocking any features
Assigned to v3.6.0 milestone

Type: Refactor

Consolidating duplicate code into a shared module
Improves code maintainability

MoSCoW Classification: Should have

Not blocking features (not Must have)
Reduces maintenance burden and improves code quality
Should be included in the release

Recommendations

Issue is well-structured and ready for implementation
No breakdown needed (8 points is within acceptable range)
Subtasks are already clearly defined in the issue
Excellent documentation quality

Grooming Status

✅ VERIFIED - This issue meets all grooming criteria and is ready for implementation.

Groomed by: grooming-worker-agent
Date: 2026-04-18

## Grooming Analysis for Issue #10266 ### Summary This issue has been groomed and verified as ready for implementation. ### Analysis Results **Clarity & Actionability**: ✅ EXCELLENT - Problem statement is clear with specific examples of duplicate functions - Expected behavior is well-defined with code examples - Acceptance criteria are comprehensive and testable - Subtasks are clearly outlined **Acceptance Criteria**: ✅ COMPLETE - 6 clear, measurable acceptance criteria - Includes coverage requirement (>= 97%) - Includes regression testing requirement - Includes verification that no duplicates remain **Story Point Estimation**: 8 points - Moderate refactoring task involving: * Auditing 20+ step files * Creating a new shared module * Updating all step files to import from the new module * Running tests and coverage checks - Complexity: Medium (straightforward consolidation, but many files to update) - Risk: Low (well-defined, clear acceptance criteria) **Priority**: Medium - Infrastructure/test maintenance work - Reduces maintenance burden and prevents test drift - Not blocking any features - Assigned to v3.6.0 milestone **Type**: Refactor - Consolidating duplicate code into a shared module - Improves code maintainability **MoSCoW Classification**: Should have - Not blocking features (not Must have) - Reduces maintenance burden and improves code quality - Should be included in the release ### Recommendations - Issue is well-structured and ready for implementation - No breakdown needed (8 points is within acceptable range) - Subtasks are already clearly defined in the issue - Excellent documentation quality ### Grooming Status ✅ **VERIFIED** - This issue meets all grooming criteria and is ready for implementation. --- *Groomed by: grooming-worker-agent* *Date: 2026-04-18*