forked from cleveragents/cleveragents-core
78 lines
3.7 KiB
Gherkin
78 lines
3.7 KiB
Gherkin
Feature: Application Container coverage boost for _build_checkpoint_service, _build_trace_service, and _build_session_factory
|
|
As a developer
|
|
I want to exercise the _build_checkpoint_service, _build_trace_service, and _build_session_factory helper functions
|
|
So that the corresponding builder functions in container.py are covered by tests
|
|
|
|
Background:
|
|
Given a clean container state for coverage boost tests
|
|
|
|
# -----------------------------------------------------------------
|
|
# _build_checkpoint_service (lines 187-195)
|
|
# -----------------------------------------------------------------
|
|
|
|
@coverage
|
|
Scenario: Build checkpoint service with in-memory database and no lifecycle service
|
|
When I build a checkpoint service with an in-memory database URL
|
|
Then acbs the result should be a CheckpointService instance
|
|
And the checkpoint service should have a repository
|
|
And the checkpoint service should have no plan lifecycle service
|
|
|
|
@coverage
|
|
Scenario: Build checkpoint service with an explicit plan lifecycle service
|
|
Given a mock plan lifecycle service
|
|
When I build a checkpoint service with the mock plan lifecycle service
|
|
Then acbs the result should be a CheckpointService instance
|
|
And the checkpoint service should reference the mock plan lifecycle service
|
|
|
|
# -----------------------------------------------------------------
|
|
# _build_trace_service (lines 204-211)
|
|
# -----------------------------------------------------------------
|
|
|
|
@coverage
|
|
Scenario: Build trace service with in-memory database using default settings
|
|
When I build a trace service with an in-memory database URL and no explicit settings
|
|
Then acbs the result should be a TraceService instance
|
|
And the trace service should have a repository
|
|
And the trace service should have resolved settings from defaults
|
|
|
|
@coverage
|
|
Scenario: Build trace service with explicit settings
|
|
Given explicit application settings for trace service
|
|
When I build a trace service with the explicit settings
|
|
Then acbs the result should be a TraceService instance
|
|
And the trace service should use the explicitly provided settings
|
|
|
|
# -----------------------------------------------------------------
|
|
# _build_session_factory
|
|
# -----------------------------------------------------------------
|
|
|
|
Scenario: Build session factory with in-memory database returns callable sessionmaker
|
|
When I build a session factory with an in-memory database URL
|
|
Then the result should be a callable sessionmaker
|
|
And calling the session factory should produce a Session
|
|
|
|
Scenario: Build session factory with invalid URL raises an error
|
|
When I build a session factory with an invalid database URL
|
|
Then a database error should be raised when the factory is called
|
|
|
|
Scenario: Container.session_factory resolves a usable session factory
|
|
When I resolve session_factory from the container with an in-memory database URL
|
|
Then the resolved session factory should be callable
|
|
And calling the resolved session factory should produce a Session
|
|
|
|
# -----------------------------------------------------------------
|
|
# _build_skill_service (happy path + fallback)
|
|
# -----------------------------------------------------------------
|
|
|
|
@coverage
|
|
Scenario: Build skill service with in-memory database succeeds
|
|
When I build a skill service with an in-memory database URL
|
|
Then the result should be a SkillService instance
|
|
And the skill service should have a repository
|
|
|
|
@coverage
|
|
Scenario: Build skill service falls back to in-memory on DB error
|
|
When I build a skill service with an invalid database URL
|
|
Then the result should be a SkillService instance
|
|
And the skill service should have no repository
|