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
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
123 lines
5.2 KiB
Gherkin
123 lines
5.2 KiB
Gherkin
Feature: Plan lifecycle repository and service coverage
|
|
Additional scenarios to cover untested paths in LifecyclePlanRepository,
|
|
ActionRepository, PlanLifecycleService, and UnitOfWork.
|
|
|
|
Background:
|
|
Given a coverage test service backed by SQLite
|
|
|
|
# ── LifecyclePlanRepository direct tests ──
|
|
|
|
Scenario: Get plan by namespaced name
|
|
Given a coverage plan exists via the service
|
|
When I retrieve the plan by its namespaced name from the repository
|
|
Then the plan retrieved by name should match the original
|
|
|
|
Scenario: Get plan by name returns None for unknown
|
|
When I retrieve a plan by name "local/nonexistent-plan-xyz" from the repository
|
|
Then the plan-by-name result should be None
|
|
|
|
Scenario: Update plan persists child project links, arguments, and invariants
|
|
Given a coverage plan with project links and invariants exists
|
|
When I update the plan description and phase through the repository
|
|
Then the updated plan should have the new description in the DB
|
|
And the updated plan should retain project links
|
|
And the updated plan should retain arguments
|
|
And the updated plan should retain invariants
|
|
|
|
Scenario: Delete plan removes it from the database
|
|
Given a coverage plan exists via the service
|
|
When I delete the plan from the repository
|
|
Then the plan should no longer be retrievable from the DB
|
|
|
|
Scenario: Delete returns false for non-existent plan
|
|
When I delete a non-existent plan "01NONEXISTENT000000000000" from the repository
|
|
Then the plan delete result should be false
|
|
|
|
Scenario: List plans with phase filter
|
|
Given a coverage plan exists via the service
|
|
When I list plans filtered by phase "strategize"
|
|
Then the listed plans should include the coverage plan
|
|
|
|
Scenario: List plans with namespace filter
|
|
Given a coverage plan exists via the service
|
|
When I list plans filtered by namespace "local"
|
|
Then the listed plans should include the coverage plan
|
|
|
|
Scenario: List plans with action_name filter
|
|
Given a coverage plan exists via the service
|
|
When plcov I list plans filtered by action_name
|
|
Then the listed plans should include the coverage plan
|
|
|
|
Scenario: Count plans with no filters
|
|
Given a coverage plan exists via the service
|
|
When I count plans with no filters
|
|
Then the count should be at least 1
|
|
|
|
Scenario: Count plans with phase filter
|
|
Given a coverage plan exists via the service
|
|
When I count plans filtered by phase "strategize"
|
|
Then the filtered count should be at least 1
|
|
|
|
Scenario: Count plans with processing_state filter
|
|
Given a coverage plan exists via the service
|
|
When I count plans filtered by processing_state "queued"
|
|
Then the filtered count should be at least 1
|
|
|
|
Scenario: Create duplicate plan raises DuplicatePlanError
|
|
Given a coverage plan exists via the service
|
|
When I try to create a duplicate plan with the same ID
|
|
Then a DuplicatePlanError should be raised
|
|
|
|
Scenario: Update non-existent plan raises PlanNotFoundError
|
|
When I try to update a plan that does not exist in the DB
|
|
Then a PlanNotFoundError should be raised
|
|
|
|
# ── ActionRepository update path ──
|
|
|
|
Scenario: Archive action triggers action update in repository
|
|
Given a coverage action "local/cov-archive" exists
|
|
When I archive the coverage action "local/cov-archive"
|
|
Then the action "local/cov-archive" should be archived in the DB
|
|
|
|
Scenario: Action update persists inputs_schema and arguments with defaults
|
|
Given a coverage action with inputs_schema and arguments exists
|
|
When I update the coverage action with new description
|
|
Then the action should retain its inputs_schema in the DB
|
|
And the action should retain its arguments with defaults in the DB
|
|
And the action should retain its invariants in the DB
|
|
|
|
# ── PlanLifecycleService persistence fallback ──
|
|
|
|
Scenario: Get plan falls back to persistence layer when not in memory
|
|
Given a coverage plan exists via the service
|
|
When I clear the in-memory plan cache
|
|
And I retrieve the plan by ID through the service
|
|
Then the plan should be loaded from the persistence layer
|
|
|
|
# ── PlanLifecycleService constrain_apply ──
|
|
|
|
Scenario: Constrain apply marks plan as constrained
|
|
Given a coverage plan in apply-queued state
|
|
When I constrain the apply with reason "Resource limit exceeded"
|
|
Then the coverage plan processing state should be "constrained"
|
|
And the coverage plan error message should be "Resource limit exceeded"
|
|
|
|
# ── PlanLifecycleService auto_progress no-op ──
|
|
|
|
Scenario: Auto progress returns plan unchanged when not auto-progressable
|
|
Given a coverage plan exists via the service
|
|
When I call auto_progress on the plan
|
|
Then the plan should be returned unchanged
|
|
|
|
# ── UnitOfWork lifecycle_plans lazy property ──
|
|
|
|
Scenario: UnitOfWork context exposes lifecycle_plans repository
|
|
When I open a UoW transaction and access lifecycle_plans
|
|
Then the lifecycle_plans property should return a LifecyclePlanRepository
|
|
|
|
# ── UnitOfWork add, flush, refresh ──
|
|
|
|
Scenario: UnitOfWork context supports add and flush
|
|
When I use UoW context to add a raw model entity and flush
|
|
Then the entity should be queryable in the same session
|