Files
cleveragents-core/features/correction_service_coverage_boost.feature
T
freemo 051ee7c290
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 21s
CI / quality (pull_request) Successful in 31s
CI / typecheck (pull_request) Successful in 47s
CI / security (pull_request) Successful in 52s
CI / build (pull_request) Successful in 56s
CI / e2e_tests (pull_request) Successful in 5m1s
CI / integration_tests (pull_request) Successful in 5m30s
CI / unit_tests (pull_request) Successful in 5m42s
CI / docker (pull_request) Successful in 58s
CI / coverage (pull_request) Successful in 7m35s
CI / build (push) Successful in 21s
CI / docker (push) Has been skipped
CI / benchmark-regression (pull_request) Failing after 49m24s
CI / lint (push) Successful in 22s
CI / quality (push) Successful in 39s
CI / security (push) Successful in 48s
CI / typecheck (push) Successful in 1m26s
CI / benchmark-regression (push) Has been skipped
CI / e2e_tests (push) Successful in 5m53s
CI / coverage (push) Successful in 9m4s
CI / benchmark-publish (push) Successful in 19m10s
CI / integration_tests (push) Failing after 19m18s
CI / unit_tests (push) Failing after 19m20s
test(coverage): add Behave BDD tests to improve coverage across 52 source files
Added 52 new .feature files and corresponding _steps.py files targeting
previously uncovered code paths in the following areas:

- TUI layer: app, commands, persona (state/schema/registry), widgets,
  input (shell_exec, reference_parser)
- Application services: plan lifecycle/service/executor, session,
  project, repo indexing, correction, checkpoint, actor, llm_actors,
  strategy coordinator, resource file watcher, service retry wiring
- CLI commands: session, resource, repl, plan, db, automation_profile
- Domain models: retry_policy, resource_type, cost_budget,
  docker_compose_analyzer, detail_level, _sql_string_aware,
  _postgresql_helpers
- Core: circuit_breaker, retry_service_patterns
- Infrastructure: repositories, transaction_sandbox, strategy_registry,
  plugins/loader, container
- Config: settings
- Agents: plan_generation, context_analysis, auto_debug
- A2A: facade

All new tests follow the Behave/Gherkin BDD standard. Resolved step
definition collisions with unique prefixes. Fixed Alembic fileConfig
logger disabling issue (disable_existing_loggers=False).

ISSUES CLOSED: #1068
2026-03-20 21:22:10 +00:00

70 lines
4.1 KiB
Gherkin

Feature: Correction Service Coverage Boost
Additional scenarios that exercise previously uncovered code paths
in the correction_service module, specifically the event emission
logic in _emit_correction_applied (lines 80-101).
Background:
Given the csboost correction service module is imported
Scenario: Event bus receives CORRECTION_APPLIED event on successful revert
Given a csboost correction service with a working event bus
And a csboost REVERT correction request for plan "plan-1" targeting decision "dec-1"
When I csboost execute the revert correction with a simple decision tree
Then the csboost event bus should have received exactly 1 event
And the csboost emitted event should have type CORRECTION_APPLIED
And the csboost emitted event details should contain the correction id
And the csboost emitted event details should contain mode "revert"
And the csboost emitted event plan_id should be "plan-1"
Scenario: Event bus receives CORRECTION_APPLIED event on successful append
Given a csboost correction service with a working event bus
And a csboost APPEND correction request for plan "plan-2" targeting decision "dec-2"
When I csboost execute the append correction
Then the csboost event bus should have received exactly 1 event
And the csboost emitted event should have type CORRECTION_APPLIED
And the csboost emitted event details should contain mode "append"
Scenario: Event bus emit failure is caught and logged without raising
Given a csboost correction service with a failing event bus
And a csboost REVERT correction request for plan "plan-3" targeting decision "dec-3"
When I csboost execute the revert correction with a simple decision tree
Then the csboost correction result status should be APPLIED
And the csboost failing event bus emit should have been called
And csboost no exception should have propagated to the caller
Scenario: Event bus emit failure is caught on append correction
Given a csboost correction service with a failing event bus
And a csboost APPEND correction request for plan "plan-4" targeting decision "dec-4"
When I csboost execute the append correction
Then the csboost correction result status should be APPLIED
And the csboost failing event bus emit should have been called
And csboost no exception should have propagated to the caller
Scenario: Event is not emitted when correction is no longer executable
Given a csboost correction service with a working event bus
And a csboost REVERT correction request for plan "plan-5" targeting decision "dec-5"
And the csboost correction has already been executed once
When I csboost attempt to execute the revert correction again
Then the csboost correction result status should be FAILED
And the csboost event bus should have received exactly 0 new events since the second attempt
Scenario: Emitted event details contain guidance text
Given a csboost correction service with a working event bus
And a csboost REVERT correction request for plan "plan-6" targeting decision "dec-6"
And the csboost correction request has guidance "fix the regression"
When I csboost execute the revert correction with a simple decision tree
Then the csboost emitted event details should contain guidance "fix the regression"
Scenario: Emitted event details contain target_decision_id
Given a csboost correction service with a working event bus
And a csboost APPEND correction request for plan "plan-7" targeting decision "dec-7"
When I csboost execute the append correction
Then the csboost emitted event details should contain target_decision_id "dec-7"
Scenario: Event dispatched via execute_correction for revert mode with event bus
Given a csboost correction service with a working event bus
And a csboost REVERT correction request for plan "plan-8" targeting decision "dec-8"
When I csboost execute the correction via the dispatch method with a simple tree
Then the csboost event bus should have received exactly 1 event
And the csboost emitted event should have type CORRECTION_APPLIED