@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
