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
|