forked from HAL9000/cleveragents-core
freemo
32b352832f
_get_tool_registry_service in cli/commands/validation.py was manually constructing the full ToolRegistryService dependency graph (create_engine, sessionmaker, ToolRegistryRepository, ValidationAttachmentRepository) instead of delegating to the DI container. This duplicated wiring logic that belongs exclusively in the container and made the function harder to test. Changes: - Add _build_tool_registry_service() builder function to container.py following the established _build_skill_service/_build_session_service pattern - Register tool_registry_service as a Singleton provider in the Container class - Refactor _get_tool_registry_service() to delegate to container.tool_registry_service() — a one-liner consistent with _get_skill_service() in cli/commands/skill.py - Add TDD Behave feature (tdd_di_tool_registry_service.feature) with two scenarios: (1) function delegates to container, (2) container exposes the provider — both scenarios were failing before this fix - Update validation_cli_uncovered_branches_steps.py to match the new container-delegation pattern (mock container.tool_registry_service() instead of container.database_url()) ISSUES CLOSED: #3006
24 lines
1.2 KiB
Gherkin
24 lines
1.2 KiB
Gherkin
@tdd @di @tool_registry
|
|
Feature: DI container resolution for _get_tool_registry_service
|
|
As a developer maintaining the CleverAgents codebase
|
|
I want _get_tool_registry_service to use the DI container directly
|
|
So that service wiring is consistent and not duplicated manually
|
|
|
|
Background:
|
|
Given a tdd di tool registry test runner
|
|
|
|
# TDD: This scenario should FAIL before the fix is applied.
|
|
# After the fix, _get_tool_registry_service must call
|
|
# container.tool_registry_service() instead of manually constructing
|
|
# the service with create_engine / sessionmaker / repositories.
|
|
Scenario: _get_tool_registry_service delegates to container.tool_registry_service
|
|
Given the DI container has a tool_registry_service provider
|
|
When _get_tool_registry_service is called with the mocked container
|
|
Then the returned service should be the one from container.tool_registry_service
|
|
And no manual engine or sessionmaker construction should have occurred
|
|
|
|
Scenario: ToolRegistryService is registered in the DI container
|
|
Given the application DI container is initialised
|
|
When the tool_registry_service provider is accessed on the container
|
|
Then the container should expose a tool_registry_service provider
|