freemo
55aee7cf22
CI / lint (pull_request) Successful in 18s
CI / quality (pull_request) Successful in 21s
CI / benchmark-publish (pull_request) Has been skipped
CI / build (pull_request) Successful in 14s
CI / security (pull_request) Successful in 49s
CI / typecheck (pull_request) Successful in 56s
CI / integration_tests (pull_request) Successful in 2m35s
CI / unit_tests (pull_request) Successful in 14m30s
CI / docker (pull_request) Successful in 55s
CI / benchmark-regression (pull_request) Successful in 21m11s
CI / coverage (pull_request) Successful in 34m22s
CI / lint (push) Successful in 12s
CI / build (push) Successful in 16s
CI / quality (push) Successful in 17s
CI / security (push) Successful in 29s
CI / typecheck (push) Successful in 1m0s
CI / benchmark-regression (push) Has been skipped
CI / integration_tests (push) Successful in 4m54s
CI / benchmark-publish (push) Successful in 11m48s
CI / unit_tests (push) Successful in 16m30s
CI / docker (push) Successful in 28s
CI / coverage (push) Successful in 25m45s
The step_register_skills_table step called add_skill in a loop but only committed once at the end. Because SkillRepository.create() obtains a new session per call and only flushes (never commits), the intermediate sessions could be garbage-collected before the final commit, rolling back their transactions on the shared SQLite :memory: connection. Moving _commit_pending inside the loop ensures each skill is durably committed before the next session is created. ISSUES CLOSED: #418
78 lines
4.0 KiB
Gherkin
78 lines
4.0 KiB
Gherkin
@phase1 @database @models @missing_coverage
|
|
Feature: Database models missing coverage for lines 1666, 1921, 2131-2132
|
|
As a developer
|
|
I want to exercise the remaining uncovered lines in database models
|
|
So that code coverage reaches 100%
|
|
|
|
Background:
|
|
Given the missing coverage database is ready
|
|
And a missing coverage database session is open
|
|
|
|
# -------------------------------------------------------------------
|
|
# ToolModel.from_domain() with a dict (covers line 1666)
|
|
# -------------------------------------------------------------------
|
|
|
|
@tool @from_domain @dict_input
|
|
Scenario: ToolModel.from_domain creates model from a plain dict
|
|
Given a tool definition provided as a plain dict
|
|
When the tool dict is converted to a ToolModel via from_domain
|
|
Then the ToolModel should have the correct name from the dict
|
|
And the ToolModel should have the correct description from the dict
|
|
And the ToolModel should have the correct tool_type from the dict
|
|
And the ToolModel should have the correct source from the dict
|
|
|
|
@tool @from_domain @dict_input @resource_bindings
|
|
Scenario: ToolModel.from_domain populates resource bindings from dict input
|
|
Given a tool definition provided as a plain dict with resource bindings
|
|
When the tool dict with bindings is converted to a ToolModel via from_domain
|
|
Then the ToolModel should have resource binding child records
|
|
And each resource binding should have the correct slot_name
|
|
And each resource binding should have the correct resource_type
|
|
|
|
@tool @from_domain @dict_input @namespace
|
|
Scenario: ToolModel.from_domain correctly splits namespaced name from dict
|
|
Given a tool definition dict with a namespaced name
|
|
When the namespaced tool dict is converted to a ToolModel via from_domain
|
|
Then the ToolModel namespace should be extracted from the dict name
|
|
And the ToolModel short_name should be extracted from the dict name
|
|
|
|
# -------------------------------------------------------------------
|
|
# SessionModel.from_domain() with messages (covers line 1921)
|
|
# -------------------------------------------------------------------
|
|
|
|
@session @from_domain @messages
|
|
Scenario: SessionModel.from_domain populates message child models
|
|
Given a Session domain object with two messages
|
|
When the Session domain object is converted to a SessionModel via from_domain
|
|
Then the SessionModel should have two message child records
|
|
And the first message record should have role "user"
|
|
And the second message record should have role "assistant"
|
|
And each message record should have the correct content
|
|
|
|
@session @from_domain @messages @single
|
|
Scenario: SessionModel.from_domain handles a session with a single message
|
|
Given a Session domain object with one message
|
|
When the single-message Session is converted to a SessionModel via from_domain
|
|
Then the SessionModel should have one message child record
|
|
And the single message record should have the correct message_id
|
|
|
|
# -------------------------------------------------------------------
|
|
# SkillModel.from_domain() exercises column definitions (covers 2131-2132)
|
|
# -------------------------------------------------------------------
|
|
|
|
@skill @from_domain @columns
|
|
Scenario: SkillModel.from_domain creates model with description and version
|
|
Given a skill definition dict with description and version
|
|
When the skill dict is converted to a SkillModel via from_domain
|
|
Then the SkillModel should have the correct description
|
|
And the SkillModel should have the correct version
|
|
And the SkillModel should have the correct namespace
|
|
And the SkillModel should have the correct short_name
|
|
|
|
@skill @from_domain @no_version
|
|
Scenario: SkillModel.from_domain handles skill without version
|
|
Given a skill definition dict without a version field
|
|
When the versionless skill dict is converted to a SkillModel via from_domain
|
|
Then the SkillModel version should be None
|
|
And the SkillModel description should still be set
|