Files
cleveragents-core/features/plan_executor_coverage_boost.feature
T
Dev User a3ba3c3eaf fix(tests): resolve pre-existing AmbiguousStep collisions in step definitions
Rename step texts to avoid case-sensitive conflicts between different step modules:

- edge_case_plan_steps.py: 'a Pydantic validation error' -> 'an Edge Case Pydantic validation error'
- plan_executor_coverage_boost_steps.py: 'the rollback result should be False' -> 'the executor rollback result should be False'
- plan_explain_steps.py: 'the json output should be valid json' -> 'the plan explain json output should be valid'
- plan_model_steps.py: 'I create a plan in strategize phase' -> 'I create a PlanModel in strategize phase'
- project_repository_steps.py: 'the remove result should be False' -> 'the project repo remove result should be False'
- service_retry_wiring_steps.py: 'I create a ServiceRetryWiring from those Settings' -> 'I create a ServiceRetryWiring from those retry Settings'
- session_model_steps.py: 'I get the session CLI dict' -> 'I get the session model CLI dict'

These pre-existing bugs prevented all behave tests from loading.
2026-05-07 20:05:33 +00:00

64 lines
2.9 KiB
Gherkin

Feature: PlanExecutor Coverage Boost
Additional scenarios that exercise previously uncovered code paths
in plan_executor.py, targeting lines 328-335, 384, 422, 458,
598-599, 612, and 619.
Background:
Given the plan executor module is imported
# --- _try_emit_metric success path (lines 328-330) ---
Scenario: _try_emit_metric emits a metric when emitter is configured
Given a PlanExecutor with a mock metrics emitter
When I trigger metric emission with a valid key and value
Then the metrics emitter should have received exactly one entry
# --- _try_emit_metric exception path (lines 331-335) ---
Scenario: _try_emit_metric silently handles emission failure
Given a PlanExecutor with a failing metrics emitter
When I trigger metric emission that causes an exception
Then no exception should propagate from metric emission
# --- _try_create_checkpoint returns None when sandbox is None (line 384) ---
Scenario: _try_create_checkpoint returns None when no sandbox is resolvable
Given a PlanExecutor with a checkpoint manager but no sandbox source
When I attempt to create a plan executor checkpoint
Then the checkpoint result should be None
# --- _try_rollback_to_last_checkpoint returns False when sandbox is None (line 422) ---
Scenario: _try_rollback_to_last_checkpoint returns False when no sandbox is resolvable
Given a PlanExecutor with a checkpoint manager but no sandbox source
When I attempt to rollback to the last checkpoint
Then the executor rollback result should be False
# --- _resolve_sandbox_for_checkpoint via execution_context (line 458) ---
Scenario: _resolve_sandbox_for_checkpoint returns sandbox from execution context
Given a PlanExecutor with an execution context that has a sandbox manager
When I resolve a sandbox for checkpointing
Then the resolved sandbox should come from the execution context
# --- _enforce_guardrails raises PlanError on step limit (lines 598-599) ---
Scenario: _enforce_guardrails raises PlanError when step limit is already reached
Given a PlanExecutor with a guardrail service that blocks step limit
When I enforce guardrails for a plan
Then a PlanError about step limit should be raised
# --- _enforce_guardrails_per_step returns when guardrails is None (line 612) ---
Scenario: _enforce_guardrails_per_step returns early when guardrails is None
Given a PlanExecutor with a guardrail service that returns no guardrails
When I enforce per-step guardrails
Then no exception should be raised from per-step enforcement
# --- _enforce_guardrails_per_step raises PlanError on wall-clock (line 619) ---
Scenario: _enforce_guardrails_per_step raises PlanError when wall-clock exceeded
Given a PlanExecutor with a guardrail service that blocks wall-clock per step
When I enforce per-step guardrails expecting wall-clock error
Then a PlanError about wall-clock limit should be raised from per-step