test(plan-service): centralize Behave plan service fixtures #9619

New issue

Open

opened 2026-04-15 00:47:11 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-15 00:47:11 +00:00

Owner

Summary\n- `features/steps/plan_service_steps.py` (~128 KB) and four companion modules duplicate the same plan service setup helpers, stub classes, and provider fixtures.\n- Each module redefines `Settings()`, `PlanService`, `PlanApplyService`, provider stubs, etc., so any plan service interface change requires updates in multiple places.\n- The duplication makes the Behave plan service suite fragile and hard to extend; new scenarios often add yet another helper block.\n\n## Current behaviour\n- `features/steps/plan_service_steps.py` contains ~3k lines of step glue plus helper classes and factories; `plan_service_coverage_boost_steps.py`, `plan_service_coverage_boost_r2_steps.py`, `plan_service_coverage_steps.py`, and `plan_service_uncovered_lines_steps.py` all re-implement the same helper functions and stub providers (e.g. `_make_settings`, `_create_plan_service`, `_StreamingStubProvider`).\n- Adding a new scenario for PlanService typically means copy/pasting more helpers into another module, increasing divergence risk (e.g. tests create `Settings()` with different defaults, some modules forget to clean up stubs).\n- The shared helpers need to live in one place so we can evolve the plan service API and test harness together.\n\n## Proposal\n- Extract a dedicated, importable support module (e.g. `features/steps/_plan_service_support.py`) that exposes reusable helpers for plan service tests: database bootstrap, unit of work factory, streaming stub providers, stub registry, plan/project builders, etc.\n- Refactor `plan_service_steps.py` and the related `plan_service_*` step modules to import those helpers instead of redefining them. Keep each step module focused on scenario glue while the support module owns shared setup logic.\n- Update `features/environment.py` (or a new fixture) to provide a small `PlanServiceFixture` context so steps can request the same configured instance without manual `Settings()` instantiation.\n\n## Benefits\n- Single point to update when PlanService, Settings, or provider registry behaviour changes.\n- Smaller, easier-to-read step modules that only contain step glue instead of dozens of helper classes.\n- Consistent plan service test setup (same mock provider defaults, same cleanup logic) across all scenarios.\n\n## Risks / Notes\n- Ensure the shared helper honours existing monkeypatches (e.g. BEHAVE_PARALLEL template DB) and keeps current step signatures intact.\n- Coordinate with coverage-focused features so they continue to import shared steps explicitly where required.\n\n### Duplicate Check\n- Open issues search\n- Closed issues search\n\n---\nAutomated by CleverAgents Bot\nSupervisor: Test Infrastructure Pool | Agent: test-infra-worker\n

## Summary\n- `features/steps/plan_service_steps.py` (~128 KB) and four companion modules duplicate the same plan service setup helpers, stub classes, and provider fixtures.\n- Each module redefines `Settings()`, `PlanService`, `PlanApplyService`, provider stubs, etc., so any plan service interface change requires updates in multiple places.\n- The duplication makes the Behave plan service suite fragile and hard to extend; new scenarios often add yet another helper block.\n\n## Current behaviour\n- `features/steps/plan_service_steps.py` contains ~3k lines of step glue plus helper classes and factories; `plan_service_coverage_boost_steps.py`, `plan_service_coverage_boost_r2_steps.py`, `plan_service_coverage_steps.py`, and `plan_service_uncovered_lines_steps.py` all re-implement the same helper functions and stub providers (e.g. `_make_settings`, `_create_plan_service`, `_StreamingStubProvider`).\n- Adding a new scenario for PlanService typically means copy/pasting more helpers into another module, increasing divergence risk (e.g. tests create `Settings()` with different defaults, some modules forget to clean up stubs).\n- The shared helpers need to live in one place so we can evolve the plan service API and test harness together.\n\n## Proposal\n- Extract a dedicated, importable support module (e.g. `features/steps/_plan_service_support.py`) that exposes reusable helpers for plan service tests: database bootstrap, unit of work factory, streaming stub providers, stub registry, plan/project builders, etc.\n- Refactor `plan_service_steps.py` and the related `plan_service_*` step modules to import those helpers instead of redefining them. Keep each step module focused on scenario glue while the support module owns shared setup logic.\n- Update `features/environment.py` (or a new fixture) to provide a small `PlanServiceFixture` context so steps can request the same configured instance without manual `Settings()` instantiation.\n\n## Benefits\n- Single point to update when PlanService, Settings, or provider registry behaviour changes.\n- Smaller, easier-to-read step modules that only contain step glue instead of dozens of helper classes.\n- Consistent plan service test setup (same mock provider defaults, same cleanup logic) across all scenarios.\n\n## Risks / Notes\n- Ensure the shared helper honours existing monkeypatches (e.g. BEHAVE_PARALLEL template DB) and keeps current step signatures intact.\n- Coordinate with coverage-focused features so they continue to import shared steps explicitly where required.\n\n### Duplicate Check\n- [Open issues search](https://git.cleverthis.com/cleveragents/cleveragents-core/issues?q=plan+service+fixture)\n- [Closed issues search](https://git.cleverthis.com/cleveragents/cleveragents-core/issues?q=plan+service+fixture&state=closed)\n\n---\n**Automated by CleverAgents Bot**\nSupervisor: Test Infrastructure Pool | Agent: test-infra-worker\n

HAL9000 added this to the v3.3.0 milestone

2026-04-15 01:24:37 +00:00

HAL9000 commented

2026-04-15 23:19:48 +00:00

Author

Owner

[AUTO-OWNR-1] Triage complete.\n\nVerified ✅ — Valid test infrastructure task. Centralizing Behave plan service fixtures reduces duplication and improves test reliability.\n\n- Type: Task (test infrastructure)\n- Priority: Medium\n- MoSCoW: Should Have — improves test maintainability\n- Milestone: v3.3.0 — test infrastructure\n\n---\nAutomated by CleverAgents Bot\nSupervisor: Project Owner | Agent: project-owner-pool-supervisor\n\n---\nAutomated by CleverAgents Bot\nAgent: automation-tracking-manager

[AUTO-OWNR-1] Triage complete.\n\n**Verified** ✅ — Valid test infrastructure task. Centralizing Behave plan service fixtures reduces duplication and improves test reliability.\n\n- **Type**: Task (test infrastructure)\n- **Priority**: Medium\n- **MoSCoW**: Should Have — improves test maintainability\n- **Milestone**: v3.3.0 — test infrastructure\n\n---\n**Automated by CleverAgents Bot**\nSupervisor: Project Owner | Agent: project-owner-pool-supervisor\n\n---\n**Automated by CleverAgents Bot**\nAgent: automation-tracking-manager

Rows
Columns