cleveragents/cleveragents-core

Fork 3

UAT: PR #2629 — plan_cli_coverage_r3.feature has two identical 'legacy path' apply scenarios that test the same code path #2780

New issue

Open

opened 2026-04-04 19:26:25 +00:00 by freemo · 2 comments

freemo commented

2026-04-04 19:26:25 +00:00

Owner

Metadata

Branch: fix/uat-2629-deduplicate-legacy-apply-scenarios
Commit Message: fix(tests): deduplicate identical legacy apply scenarios in plan_cli_coverage_r3.feature
Milestone: v3.2.0
Parent Epic: #2597

Background and Context

During UAT review of PR #2629 (branch fix/master-ci-quality-gates, HEAD SHA 938ea8194c6a2044b17efabea1766995c62eeaf1), two scenarios in features/plan_cli_coverage_r3.feature were found to be functionally identical despite having different titles implying they test different code paths.

The PR description states "Added new step for no-eligible-plans path (legacy apply path removed)" — the intent was to cover the no-eligible-plans path, but the two scenarios don't actually test different behaviors.

Current Behavior

In features/plan_cli_coverage_r3.feature (lines 43–55), two scenarios titled "apply command legacy path with pending changes" and "apply command legacy path with no pending changes" are functionally identical — they use the same Given/When/Then steps and the same mock:

Scenario: apply command legacy path with pending changes
  Given a plcov3 CLI runner
  And a plcov3 mocked lifecycle service with no eligible apply plans
  When I plcov3 invoke apply without plan_id
  Then the plcov3 CLI output should contain "No plans ready for apply"

Scenario: apply command legacy path with no pending changes
  Given a plcov3 CLI runner
  And a plcov3 mocked lifecycle service with no eligible apply plans
  When I plcov3 invoke apply without plan_id
  Then the plcov3 CLI output should contain "No plans ready for apply"

Both scenarios use "a plcov3 mocked lifecycle service with no eligible apply plans" which sets service.list_plans.return_value = []. The scenario titles imply they should test different paths (with pending changes vs. no pending changes), but the implementation is identical — they exercise the exact same code path twice.

Additionally, the steps file (features/steps/plan_cli_coverage_r3_steps.py) defines two step definitions that exist but are not used in the feature file:

"a plcov3 mocked legacy apply environment with pending changes" (line 273)
"a plcov3 mocked legacy apply environment with no pending changes" (line 300)

These step definitions were presumably written to support differentiated scenarios but were never wired up in the feature file.

Expected Behavior

The two scenarios should either:

(a) Be merged into one scenario — since they test the same thing, a single scenario titled "apply command with no eligible apply plans" is sufficient and avoids misleading duplication, or
(b) Be differentiated to actually test different code paths — using the appropriate unused mock step definitions ("a plcov3 mocked legacy apply environment with pending changes" and "a plcov3 mocked legacy apply environment with no pending changes") to exercise genuinely distinct behaviors.

The unused step definitions at lines 273 and 300 of features/steps/plan_cli_coverage_r3_steps.py should either be used in the feature file or removed to avoid dead test infrastructure.

Acceptance Criteria

features/plan_cli_coverage_r3.feature contains no two scenarios that are byte-for-byte identical in their step sequences.
If the two legacy-path scenarios are merged into one, the single scenario has a clear, accurate title reflecting what it tests.
If the two scenarios are differentiated, each uses a distinct mock step definition and exercises a genuinely different code path.
The unused step definitions at features/steps/plan_cli_coverage_r3_steps.py lines 273 and 300 are either referenced in the feature file or removed.
All Behave BDD scenarios in features/plan_cli_coverage_r3.feature pass (nox -s unit_tests).
Coverage remains >= 97% (nox -s coverage_report).
All nox default sessions pass with zero errors.

Supporting Information

Code location: features/plan_cli_coverage_r3.feature lines 43–55; features/steps/plan_cli_coverage_r3_steps.py lines 265–316
Discovered during: UAT review of PR #2629 (branch fix/master-ci-quality-gates, HEAD SHA 938ea8194c6a2044b17efabea1766995c62eeaf1)
Related PR: #2629
Parent Epic: #2597 — fix(ci): restore all CI quality gates to passing on master

Subtasks

Confirm the two scenarios in features/plan_cli_coverage_r3.feature (lines 43–55) are indeed identical in step content
Decide on resolution approach: merge into one scenario OR differentiate using existing unused step definitions
Implement chosen resolution (update feature file and/or steps file)
Remove or wire up unused step definitions at features/steps/plan_cli_coverage_r3_steps.py lines 273 and 300
Run nox -s unit_tests and confirm all scenarios pass
Run nox -s coverage_report and confirm coverage >= 97%
Run nox (all default sessions) and confirm zero errors

Definition of Done

This issue is complete when:

All subtasks above are completed and checked off.
features/plan_cli_coverage_r3.feature contains no duplicate identical scenarios.
Unused step definitions are either used or removed.
A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly (fix(tests): deduplicate identical legacy apply scenarios in plan_cli_coverage_r3.feature), followed by a blank line, then additional lines providing relevant details.
The commit is pushed to the remote on the branch matching the Branch in Metadata exactly (fix/uat-2629-deduplicate-legacy-apply-scenarios).
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%.

Automated by CleverAgents Bot
Supervisor: Acting on behalf of: UAT Testing | Agent: ca-new-issue-creator

## Metadata - **Branch**: `fix/uat-2629-deduplicate-legacy-apply-scenarios` - **Commit Message**: `fix(tests): deduplicate identical legacy apply scenarios in plan_cli_coverage_r3.feature` - **Milestone**: v3.2.0 - **Parent Epic**: #2597 ## Background and Context During UAT review of PR #2629 (branch `fix/master-ci-quality-gates`, HEAD SHA `938ea8194c6a2044b17efabea1766995c62eeaf1`), two scenarios in `features/plan_cli_coverage_r3.feature` were found to be functionally identical despite having different titles implying they test different code paths. The PR description states "Added new step for no-eligible-plans path (legacy apply path removed)" — the intent was to cover the no-eligible-plans path, but the two scenarios don't actually test different behaviors. ## Current Behavior In `features/plan_cli_coverage_r3.feature` (lines 43–55), two scenarios titled **"apply command legacy path with pending changes"** and **"apply command legacy path with no pending changes"** are functionally identical — they use the same Given/When/Then steps and the same mock: ```gherkin Scenario: apply command legacy path with pending changes Given a plcov3 CLI runner And a plcov3 mocked lifecycle service with no eligible apply plans When I plcov3 invoke apply without plan_id Then the plcov3 CLI output should contain "No plans ready for apply" Scenario: apply command legacy path with no pending changes Given a plcov3 CLI runner And a plcov3 mocked lifecycle service with no eligible apply plans When I plcov3 invoke apply without plan_id Then the plcov3 CLI output should contain "No plans ready for apply" ``` Both scenarios use `"a plcov3 mocked lifecycle service with no eligible apply plans"` which sets `service.list_plans.return_value = []`. The scenario titles imply they should test different paths (with pending changes vs. no pending changes), but the implementation is identical — they exercise the exact same code path twice. Additionally, the steps file (`features/steps/plan_cli_coverage_r3_steps.py`) defines two step definitions that exist but are **not used** in the feature file: - `"a plcov3 mocked legacy apply environment with pending changes"` (line 273) - `"a plcov3 mocked legacy apply environment with no pending changes"` (line 300) These step definitions were presumably written to support differentiated scenarios but were never wired up in the feature file. ## Expected Behavior The two scenarios should either: - **(a) Be merged into one scenario** — since they test the same thing, a single scenario titled "apply command with no eligible apply plans" is sufficient and avoids misleading duplication, **or** - **(b) Be differentiated to actually test different code paths** — using the appropriate unused mock step definitions (`"a plcov3 mocked legacy apply environment with pending changes"` and `"a plcov3 mocked legacy apply environment with no pending changes"`) to exercise genuinely distinct behaviors. The unused step definitions at lines 273 and 300 of `features/steps/plan_cli_coverage_r3_steps.py` should either be used in the feature file or removed to avoid dead test infrastructure. ## Acceptance Criteria 1. `features/plan_cli_coverage_r3.feature` contains no two scenarios that are byte-for-byte identical in their step sequences. 2. If the two legacy-path scenarios are merged into one, the single scenario has a clear, accurate title reflecting what it tests. 3. If the two scenarios are differentiated, each uses a distinct mock step definition and exercises a genuinely different code path. 4. The unused step definitions at `features/steps/plan_cli_coverage_r3_steps.py` lines 273 and 300 are either referenced in the feature file or removed. 5. All Behave BDD scenarios in `features/plan_cli_coverage_r3.feature` pass (`nox -s unit_tests`). 6. Coverage remains >= 97% (`nox -s coverage_report`). 7. All nox default sessions pass with zero errors. ## Supporting Information - **Code location**: `features/plan_cli_coverage_r3.feature` lines 43–55; `features/steps/plan_cli_coverage_r3_steps.py` lines 265–316 - **Discovered during**: UAT review of PR #2629 (branch `fix/master-ci-quality-gates`, HEAD SHA `938ea8194c6a2044b17efabea1766995c62eeaf1`) - **Related PR**: #2629 - **Parent Epic**: #2597 — fix(ci): restore all CI quality gates to passing on master ## Subtasks - [ ] Confirm the two scenarios in `features/plan_cli_coverage_r3.feature` (lines 43–55) are indeed identical in step content - [ ] Decide on resolution approach: merge into one scenario OR differentiate using existing unused step definitions - [ ] Implement chosen resolution (update feature file and/or steps file) - [ ] Remove or wire up unused step definitions at `features/steps/plan_cli_coverage_r3_steps.py` lines 273 and 300 - [ ] Run `nox -s unit_tests` and confirm all scenarios pass - [ ] Run `nox -s coverage_report` and confirm coverage >= 97% - [ ] Run `nox` (all default sessions) and confirm zero errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - `features/plan_cli_coverage_r3.feature` contains no duplicate identical scenarios. - Unused step definitions are either used or removed. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly (`fix(tests): deduplicate identical legacy apply scenarios in plan_cli_coverage_r3.feature`), followed by a blank line, then additional lines providing relevant details. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly (`fix/uat-2629-deduplicate-legacy-apply-scenarios`). - 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%. --- **Automated by CleverAgents Bot** Supervisor: Acting on behalf of: UAT Testing | Agent: ca-new-issue-creator

freemo added this to the v3.2.0 milestone

2026-04-04 19:26:31 +00:00

freemo added a new dependency

2026-04-04 19:26:39 +00:00

#2597 fix(ci): restore all CI quality gates to passing on master — no suppression, no bypasses

freemo added the

MoSCoW

Could have

label

2026-04-04 19:30:48 +00:00

freemo commented

2026-04-04 19:31:08 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified | MoSCoW: Could Have — Duplicate test scenarios are a code quality issue but not blocking functionality.

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

Issue triaged by project owner: - **State**: Verified | **MoSCoW**: Could Have — Duplicate test scenarios are a code quality issue but not blocking functionality. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner

freemo referenced this issue

2026-04-04 19:31:54 +00:00

[CA-AUTO] UAT Pool Supervisor — PR #2629 Validation — Session Tracker #2752

freemo referenced this issue

2026-04-04 19:32:11 +00:00

fix(ci): restore all CI quality gates to passing on master #2629

freemo referenced this issue

2026-04-04 19:36:21 +00:00

[CA-AUTO] UAT Pool Supervisor — PR #2629 Validation — Session Tracker #2752

freemo referenced this issue

2026-04-04 19:42:22 +00:00

[CA-AUTO] System Watchdog Session State (watchdog-1) #2756

freemo referenced this issue

2026-04-04 20:42:57 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.7.0 — Session Tracker #2803

freemo referenced this issue

2026-04-04 21:08:24 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.7.0 — Session Tracker #2803

freemo removed a dependency

2026-04-05 04:34:06 +00:00

#2597 fix(ci): restore all CI quality gates to passing on master — no suppression, no bypasses

freemo removed this from the v3.2.0 milestone

2026-04-06 22:29:23 +00:00

freemo commented

2026-04-06 22:29:40 +00:00

Author

Owner

This issue has been moved to the backlog as part of an aggressive grooming of the v3.2.0 milestone. It has been deemed non-critical for the minimal viability of the milestone and will be addressed in a future release.