Files
cleveragents-core/features/database_models_coverage_boost.feature
Jeffrey Phillips Freeman 36c571db83
CI / lint (pull_request) Successful in 15s
CI / typecheck (pull_request) Successful in 30s
CI / security (pull_request) Successful in 22s
CI / quality (pull_request) Successful in 16s
CI / integration_tests (pull_request) Successful in 5m12s
CI / build (pull_request) Successful in 16s
CI / lint (push) Successful in 13s
CI / typecheck (push) Successful in 29s
CI / security (push) Successful in 23s
CI / quality (push) Successful in 16s
CI / unit_tests (pull_request) Successful in 13m42s
CI / integration_tests (push) Successful in 4m53s
CI / build (push) Successful in 16s
CI / unit_tests (push) Successful in 15m9s
CI / coverage (pull_request) Successful in 7m58s
CI / coverage (push) Successful in 8m14s
CI / docker (pull_request) Successful in 9s
CI / docker (push) Successful in 8s
feat(repo): add resource repositories
2026-02-16 21:35:54 +00:00

133 lines
6.8 KiB
Gherkin

@phase1 @database @models @coverage_boost
Feature: Database model coverage boost for uncovered branches
As a developer
I want to exercise uncovered branches in to_domain and from_domain conversions
So that database model code coverage increases
Background:
Given the coverage boost database is ready
And a coverage boost database session is open
# -------------------------------------------------------------------
# LifecycleActionModel.to_domain: default_value_json and inputs_schema_json
# -------------------------------------------------------------------
@action @to_domain @default_value
Scenario: Action to_domain deserializes argument default values from JSON
Given an action model exists with arguments that have default values set
When the action model is converted to a domain object
Then the domain action argument should have the correct default value
And the domain action argument without a default should have None
@action @to_domain @inputs_schema
Scenario: Action to_domain deserializes inputs_schema from JSON
Given an action model exists with inputs_schema_json populated
When the action model is converted to a domain object
Then the domain action should have the parsed inputs_schema dict
# -------------------------------------------------------------------
# LifecycleActionModel.from_domain: inputs_schema, default_value, invariants
# -------------------------------------------------------------------
@action @from_domain @inputs_schema
Scenario: Action from_domain serializes inputs_schema to JSON
Given an action domain object with inputs_schema set
When the action domain object is converted to a database model
Then the database model should have inputs_schema_json as a JSON string
@action @from_domain @default_value
Scenario: Action from_domain serializes argument default values to JSON
Given an action domain object with arguments that have default values
When the action domain object is converted to a database model
Then the database model arguments should have default_value_json set
And the argument without a default should have null default_value_json
@action @from_domain @invariants
Scenario: Action from_domain populates invariants child models
Given an action domain object with invariants defined
When the action domain object is converted to a database model
Then the database model should have invariant child records
And each invariant child record should have correct text and position
# -------------------------------------------------------------------
# LifecyclePlanModel.to_domain: automation_profile, sandbox_refs, validation_summary, error_details
# -------------------------------------------------------------------
@plan @to_domain @automation_profile
Scenario: Plan to_domain deserializes automation_profile from JSON
Given a plan model exists with automation_profile JSON set
When the plan model is converted to a domain object
Then the domain plan should have an automation profile with the correct name
And the domain plan automation profile should have the correct provenance
@plan @to_domain @sandbox_refs
Scenario: Plan to_domain deserializes sandbox_refs from JSON
Given a plan model exists with sandbox_refs_json populated
When the plan model is converted to a domain object
Then the domain plan should have the parsed sandbox refs list
@plan @to_domain @validation_summary
Scenario: Plan to_domain deserializes validation_summary from JSON
Given a plan model exists with validation_summary_json populated
When the plan model is converted to a domain object
Then the domain plan should have the parsed validation summary dict
@plan @to_domain @error_details
Scenario: Plan to_domain deserializes error_details from JSON
Given a plan model exists with error_details_json populated
When the plan model is converted to a domain object
Then the domain plan should have the parsed error details dict
@plan @to_domain @arguments
Scenario: Plan to_domain deserializes arguments from child table
Given a plan model exists with argument child records
When the plan model is converted to a domain object
Then the domain plan should have the arguments dict populated
And the domain plan should have arguments_order populated
# -------------------------------------------------------------------
# LifecyclePlanModel.from_domain: project_links, invariants, arguments
# -------------------------------------------------------------------
@plan @from_domain @project_links
Scenario: Plan from_domain populates project link child models
Given a plan domain object with project links defined
When the plan domain object is converted to a database model via from_domain
Then the database plan model should have project link child records
And each project link child record should have the correct project name
@plan @from_domain @invariants
Scenario: Plan from_domain populates invariant child models
Given a plan domain object with plan invariants defined
When the plan domain object is converted to a database model via from_domain
Then the database plan model should have invariant child records with source
And each plan invariant child record should have correct text and source
@plan @from_domain @arguments
Scenario: Plan from_domain populates argument child models
Given a plan domain object with arguments and arguments_order defined
When the plan domain object is converted to a database model via from_domain
Then the database plan model should have argument child records
And each plan argument child record should have correct name and value
# -------------------------------------------------------------------
# NamespacedProjectModel.to_domain: resource_links
# -------------------------------------------------------------------
@project @to_domain @resource_links
Scenario: Project to_domain builds linked resources from child relationship
Given a project model exists with resource link child records
When the project model is converted to a domain object
Then the domain project should have linked resources populated
And each linked resource should have the correct resource id and alias
# -------------------------------------------------------------------
# NamespacedProjectModel.to_domain: context_config parsing
# -------------------------------------------------------------------
@project @to_domain @context_config
Scenario: Project to_domain parses context_policy_json into ContextConfig
Given a project model exists with context_policy_json populated
When the project model is converted to a domain object
Then the domain project should have a context config with custom values