TEST-INFRA: [test-data-quality] Refactor In-Memory Stubs from Step Files to Shared Test Utilities #5404

Open
opened 2026-04-09 06:30:50 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Branch: refactor/test-data-quality/shared-test-stubs
  • Commit Message: refactor(tests): extract in-memory stub classes from step files into shared features/mocks/ module
  • Milestone: (none — see backlog note below)
  • Parent Epic: #1678

Backlog note: This issue was discovered during autonomous operation
on milestone v3.5.0. It does not block milestone completion and has been
placed in the backlog for human review and future milestone assignment.

Background and context

During an analysis of the test infrastructure, it was observed that several Behave step implementation files define in-memory stub classes for repositories, units of work, and other dependencies directly within the step files. An example of this pattern can be found in features/steps/actor_service_steps.py with the _StubActorRepository, _StubTransaction, and _StubUnitOfWork classes.

While this approach achieves test isolation, it leads to several issues:

  • Code Duplication: The same stub classes are likely to be re-implemented or copied across different step files, leading to code duplication.
  • Reduced Readability: The presence of large stub classes in step files makes them harder to read and understand.
  • Maintenance Overhead: If the interface of a dependency changes, all the corresponding stub classes need to be updated in multiple places.

Expected behavior

To improve the quality and maintainability of the test suite, the in-memory stub classes should be refactored into a shared test utility module. This will:

  • Promote Reusability: The stub classes can be reused across different feature tests.
  • Improve Readability: The step files will be cleaner and more focused on the test logic.
  • Reduce Maintenance Overhead: The stub classes will be defined in a single place, making them easier to update.

Per CONTRIBUTING.md, all mocking code, test doubles, and test-only implementations are strictly confined to the features/mocks/ directory.

Subtasks

  • Identify all the step implementation files that define in-memory stub classes.
  • Create a new shared test utility module (e.g., features/mocks/stubs/ or extend existing features/mocks/).
  • Move the in-memory stub classes from the step files to the new shared module.
  • Update the step files to import and use the stub classes from the shared module.
  • Ensure that all tests pass after the refactoring.

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • A Git commit is created where the first line of the commit message
    matches the Commit Message in Metadata exactly, followed by a blank line,
    then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in
    Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and
    merged before this issue is marked done.
  • All nox stages pass.
  • Coverage >= 97%.

Duplicate Check

  • Search queries: "test stubs", "test doubles", "refactor tests"
  • Results: 0 for all queries.
  • Reasoning: No existing issues cover the refactoring of in-memory stubs from step files to shared test utilities.

Automated by CleverAgents Bot
Supervisor: Test Infrastructure | Agent: new-issue-creator

## Metadata - **Branch**: `refactor/test-data-quality/shared-test-stubs` - **Commit Message**: `refactor(tests): extract in-memory stub classes from step files into shared features/mocks/ module` - **Milestone**: *(none — see backlog note below)* - **Parent Epic**: #1678 > **Backlog note:** This issue was discovered during autonomous operation > on milestone v3.5.0. It does not block milestone completion and has been > placed in the backlog for human review and future milestone assignment. ## Background and context During an analysis of the test infrastructure, it was observed that several Behave step implementation files define in-memory stub classes for repositories, units of work, and other dependencies directly within the step files. An example of this pattern can be found in `features/steps/actor_service_steps.py` with the `_StubActorRepository`, `_StubTransaction`, and `_StubUnitOfWork` classes. While this approach achieves test isolation, it leads to several issues: * **Code Duplication:** The same stub classes are likely to be re-implemented or copied across different step files, leading to code duplication. * **Reduced Readability:** The presence of large stub classes in step files makes them harder to read and understand. * **Maintenance Overhead:** If the interface of a dependency changes, all the corresponding stub classes need to be updated in multiple places. ## Expected behavior To improve the quality and maintainability of the test suite, the in-memory stub classes should be refactored into a shared test utility module. This will: * **Promote Reusability:** The stub classes can be reused across different feature tests. * **Improve Readability:** The step files will be cleaner and more focused on the test logic. * **Reduce Maintenance Overhead:** The stub classes will be defined in a single place, making them easier to update. Per `CONTRIBUTING.md`, all mocking code, test doubles, and test-only implementations are strictly confined to the `features/mocks/` directory. ## Subtasks - [ ] Identify all the step implementation files that define in-memory stub classes. - [ ] Create a new shared test utility module (e.g., `features/mocks/stubs/` or extend existing `features/mocks/`). - [ ] Move the in-memory stub classes from the step files to the new shared module. - [ ] Update the step files to import and use the stub classes from the shared module. - [ ] Ensure that all tests pass after the refactoring. ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. - All nox stages pass. - Coverage >= 97%. ### Duplicate Check - **Search queries:** "test stubs", "test doubles", "refactor tests" - **Results:** 0 for all queries. - **Reasoning:** No existing issues cover the refactoring of in-memory stubs from step files to shared test utilities. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure | Agent: new-issue-creator
Author
Owner

Issue triaged by project owner:

  • State: Verified
  • Priority: Medium — Refactoring in-memory stubs to shared features/mocks/ is a code quality improvement that reduces duplication and maintenance overhead. It doesn't block any milestone but improves long-term maintainability.
  • Milestone: None (backlog — as noted in issue body)
  • Story Points: 3 — M — Identifying stub classes across step files and moving them to a shared module is a focused refactoring task, 4-8 hours.
  • MoSCoW: MoSCoW/Should have — Per CONTRIBUTING.md, all mocking code MUST be in features/mocks/. This refactoring brings the codebase into compliance with the project standard. It's important but not blocking.
  • Parent Epic: #1678 (as noted in issue body)

This is a valid refactoring issue that enforces the CONTRIBUTING.md rule that all test doubles must live in features/mocks/. Well-documented with clear subtasks and DoD.


Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Medium — Refactoring in-memory stubs to shared `features/mocks/` is a code quality improvement that reduces duplication and maintenance overhead. It doesn't block any milestone but improves long-term maintainability. - **Milestone**: None (backlog — as noted in issue body) - **Story Points**: 3 — M — Identifying stub classes across step files and moving them to a shared module is a focused refactoring task, 4-8 hours. - **MoSCoW**: MoSCoW/Should have — Per CONTRIBUTING.md, all mocking code MUST be in `features/mocks/`. This refactoring brings the codebase into compliance with the project standard. It's important but not blocking. - **Parent Epic**: #1678 (as noted in issue body) This is a valid refactoring issue that enforces the CONTRIBUTING.md rule that all test doubles must live in `features/mocks/`. Well-documented with clear subtasks and DoD. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#5404
No description provided.