freemo
a808c395f9
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 15s
CI / build (pull_request) Successful in 15s
CI / quality (pull_request) Successful in 17s
CI / typecheck (pull_request) Successful in 35s
CI / security (pull_request) Successful in 50s
CI / unit_tests (pull_request) Successful in 2m46s
CI / integration_tests (pull_request) Successful in 3m16s
CI / docker (pull_request) Successful in 40s
CI / coverage (pull_request) Successful in 5m6s
CI / lint (push) Successful in 13s
CI / quality (push) Successful in 16s
CI / build (push) Successful in 18s
CI / security (push) Successful in 32s
CI / typecheck (push) Successful in 35s
CI / benchmark-regression (push) Has been skipped
CI / unit_tests (push) Successful in 2m52s
CI / integration_tests (push) Successful in 3m8s
CI / docker (push) Successful in 39s
CI / coverage (push) Successful in 5m53s
CI / benchmark-publish (push) Successful in 16m55s
CI / benchmark-regression (pull_request) Successful in 33m0s
Add 53 new .feature files and corresponding step definition files targeting uncovered lines identified in build/coverage.xml. Fix AmbiguousStep conflicts in 7 pre-existing step files by disambiguating step text. New tests cover: ACP clients/facade, actor CLI/config, application container, ACMS service/strategies, async worker, automation profile CLI, autonomy guardrail, bridge, change model, config CLI/service, context service, cross-plan correction, database models, decision service, decomposition clustering/service, discovery handler, langchain chat provider, langgraph nodes, materializers, multi-project service, plan apply/CLI/lifecycle/model/ preflight/resume/service, PostgreSQL analyzer, project CLI/context CLI, provider registry, reactive application/route, repositories, resolver handler, resource registry service, resume model, retry patterns, sandbox protocol, server CLI, skill CLI/service, skills registry, subplan execution/service, system CLI, UKO loader, UoW, and YAML template engine. Closes #645
114 lines
5.7 KiB
Gherkin
114 lines
5.7 KiB
Gherkin
Feature: Database models coverage round 2
|
|
Additional Behave scenarios targeting uncovered lines in
|
|
src/cleveragents/infrastructure/database/models.py identified
|
|
from build/coverage.xml.
|
|
|
|
# ---------------------------------------------------------------
|
|
# LifecycleActionModel — safety_profile round-trip (lines 376, 427)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: LifecycleActionModel to_domain deserializes safety_profile_json
|
|
Given a LifecycleActionModel with safety_profile_json populated
|
|
When I convert the action model to domain via to_domain
|
|
Then the domain action has a non-null safety_profile object
|
|
|
|
Scenario: LifecycleActionModel from_domain serializes safety_profile
|
|
Given an Action domain object with a SafetyProfile attached
|
|
When I convert the action to a model via from_domain
|
|
Then the model safety_profile_json contains serialized SafetyProfile data
|
|
|
|
# ---------------------------------------------------------------
|
|
# LifecycleActionModel — string arg_type/requirement (lines 466, 469)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: LifecycleActionModel from_domain with plain-string arg_type and requirement
|
|
Given an Action domain object whose arguments have plain-string arg_type and requirement
|
|
When I convert that action to a model via from_domain
|
|
Then the model argument rows use the plain-string values directly
|
|
|
|
# ---------------------------------------------------------------
|
|
# LifecyclePlanModel — string processing_state (line 882)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: LifecyclePlanModel from_domain with string processing_state
|
|
Given a Plan domain object whose processing_state is a plain string
|
|
When I convert the plan to a model via from_domain
|
|
Then the model processing_state equals the plain string value
|
|
|
|
# ---------------------------------------------------------------
|
|
# LifecyclePlanModel — automation_profile serialization (line 890)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: LifecyclePlanModel from_domain serializes automation_profile
|
|
Given a Plan domain object with a non-null automation_profile
|
|
When I convert the plan to a model via from_domain
|
|
Then the model automation_profile column contains JSON with profile_name
|
|
|
|
# ---------------------------------------------------------------
|
|
# LifecyclePlanModel — fallback namespace (line 906)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: LifecyclePlanModel from_domain falls back to local when namespace missing
|
|
Given a Plan domain object whose namespaced_name has no namespace attribute
|
|
When I convert the plan to a model via from_domain
|
|
Then the model namespace equals "local"
|
|
|
|
# ---------------------------------------------------------------
|
|
# LifecyclePlanModel — error_details serialization (line 923)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: LifecyclePlanModel from_domain serializes error_details
|
|
Given a Plan domain object with non-null error_details
|
|
When I convert the plan to a model via from_domain
|
|
Then the model error_details_json is a JSON string of the details dict
|
|
|
|
# ---------------------------------------------------------------
|
|
# SkillModel — include with overrides (line 2327)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: SkillModel from_domain persists include overrides
|
|
Given a Skill domain object with an include that has overrides
|
|
When I convert the skill to a model via from_domain
|
|
Then the include item_config contains the serialized overrides
|
|
|
|
# ---------------------------------------------------------------
|
|
# DecisionModel — string decision_type fallback (line 2698)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: DecisionModel from_domain with plain-string decision_type
|
|
Given a Decision domain object whose decision_type is a plain string
|
|
When I convert the decision to a model via from_domain
|
|
Then the model decision_type equals the plain string
|
|
|
|
# ---------------------------------------------------------------
|
|
# CheckpointModel — to_domain full path (lines 2823-2852)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: CheckpointModel to_domain converts all fields including metadata
|
|
Given a CheckpointModel with metadata_json containing reason and phase
|
|
When I convert the checkpoint model to domain via to_domain
|
|
Then the domain checkpoint has the correct metadata fields
|
|
|
|
Scenario: CheckpointModel to_domain handles invalid metadata_json gracefully
|
|
Given a CheckpointModel with invalid JSON in metadata_json
|
|
When I convert the checkpoint model to domain via to_domain
|
|
Then the domain checkpoint metadata is empty defaults
|
|
|
|
# ---------------------------------------------------------------
|
|
# CheckpointModel — from_domain full path (lines 2865-2879)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: CheckpointModel from_domain serializes all checkpoint fields
|
|
Given a Checkpoint domain object with full metadata
|
|
When I convert the checkpoint to a model via from_domain
|
|
Then the model has correct checkpoint_id plan_id and metadata_json
|
|
|
|
# ---------------------------------------------------------------
|
|
# get_session function (lines 2907-2908)
|
|
# ---------------------------------------------------------------
|
|
|
|
Scenario: get_session returns a usable SQLAlchemy session
|
|
Given an in-memory SQLAlchemy engine
|
|
When I call get_session with that engine
|
|
Then I receive a valid SQLAlchemy session object
|