forked from HAL9000/cleveragents-core
brent.edwards
601f408860
Route automation profile CLI service resolution through the DI container by using container.automation_profile_service() and wiring a dedicated automation_profile_service provider in the application container. This removes ad-hoc repository/session construction from the CLI path so dependency lifecycle and configuration stay centralized and consistent with specification DI rules. Add integration-style, non-mocked Behave proof that _get_service() resolves through real container/provider wiring, while keeping focused delegation assertions in the existing coverage feature. Remove the unrelated robot/resource_dag.robot changes from this PR and clean up duplicate _get_service test overlap by dropping the extra TDD-only feature file pair. ISSUES CLOSED: #990
35 lines
1.8 KiB
Gherkin
35 lines
1.8 KiB
Gherkin
Feature: Automation Profile CLI _get_service coverage boost
|
|
As a developer
|
|
I want to cover the _get_service function in automation_profile CLI module
|
|
So that DI-container delegation behavior is exercised
|
|
|
|
Background:
|
|
Given the automation profile CLI module is imported for r2 coverage
|
|
|
|
Scenario: _get_service returns the service provided by the container
|
|
Given a mock container returning an automation profile service instance
|
|
When I call _get_service directly
|
|
Then the returned object should be an AutomationProfileService instance
|
|
And the returned service should be the same object provided by the container
|
|
|
|
Scenario: _get_service calls the container provider exactly once
|
|
Given a mock container returning an automation profile service instance
|
|
When I call _get_service directly
|
|
Then the container automation profile service provider should be called once
|
|
|
|
Scenario: _get_service does not consult container database_url directly
|
|
Given a mock container returning an automation profile service instance
|
|
When I call _get_service directly
|
|
Then the container database_url provider should not be called
|
|
|
|
Scenario: _get_service returns a working DB-backed service supplied by container
|
|
Given a mock container returning a working db-backed automation profile service
|
|
When I call _get_service directly
|
|
Then the returned service should be able to list profiles without error
|
|
|
|
Scenario: _get_service resolves through real container/provider wiring
|
|
Given a real DI container configured with a temporary sqlite database
|
|
When I call _get_service directly without mocking container access
|
|
Then the returned object should be an AutomationProfileService instance
|
|
And the resolved service should include a database-backed automation profile repository
|