forked from cleveragents/cleveragents-core
CoreRasurae
67 lines
3.5 KiB
Gherkin
67 lines
3.5 KiB
Gherkin
@unit @coverage @tool_registry
|
|
Feature: Tool Registry Service - fallback method paths
|
|
As a developer maintaining the tool registry service
|
|
I want to exercise the fallback method resolution branches
|
|
So that all delegation paths in register_tool, update_tool, and remove_tool are covered
|
|
|
|
# --- register_tool fallback: no create, uses add -------------------------
|
|
|
|
Scenario: register_tool falls back to add when create does not exist
|
|
Given a tool registry service with a repo that only has add method
|
|
When I register a tool via the fallback service
|
|
Then the tool should be registered via the add method
|
|
And no error should be raised by the fallback service
|
|
|
|
Scenario: register_tool falls back to create attribute when neither create nor add are callable
|
|
Given a tool registry service with a repo that has no create or add methods
|
|
When I register a tool via the fallback service and expect error
|
|
Then a fallback AttributeError should be raised
|
|
|
|
# --- update_tool with tool_config parameter (dict) ----------------------
|
|
|
|
Scenario: update_tool with string tool name and dict config merges them
|
|
Given a tool registry service with a standard mock repo
|
|
When I update tool "local/my-tool" with dict config via the fallback service
|
|
Then the updated tool should have name "local/my-tool"
|
|
And no error should be raised by the fallback service
|
|
|
|
Scenario: update_tool with string tool name and Tool model config uses model
|
|
Given a tool registry service with a standard mock repo
|
|
When I update tool "local/my-tool" with Tool model config via the fallback service
|
|
Then the update should use the Tool model directly
|
|
And no error should be raised by the fallback service
|
|
|
|
Scenario: update_tool with dict tool and dict config uses the dict tool
|
|
Given a tool registry service with a standard mock repo
|
|
When I update with dict tool and dict config via the fallback service
|
|
Then the updated tool should be the original dict
|
|
And no error should be raised by the fallback service
|
|
|
|
# --- remove_tool fallback: no delete, uses remove -----------------------
|
|
|
|
Scenario: remove_tool falls back to remove when delete does not exist
|
|
Given a tool registry service with a repo that only has remove method
|
|
When I remove tool "local/gone" via the fallback service
|
|
Then the tool should be removed via the remove method
|
|
And no error should be raised by the fallback service
|
|
|
|
Scenario: remove_tool falls back to delete attribute when neither delete nor remove are callable
|
|
Given a tool registry service with a repo that has no delete or remove methods
|
|
When I remove tool "local/gone" via the fallback service and expect error
|
|
Then a fallback AttributeError should be raised
|
|
|
|
# --- list_tools delegates to list_all -----------------------------------
|
|
|
|
Scenario: list_tools delegates to repo list_all with filters
|
|
Given a tool registry service with a standard mock repo
|
|
When I list tools with namespace "local" and type "validation" via the fallback service
|
|
Then the list result should be returned from list_all
|
|
And no error should be raised by the fallback service
|
|
|
|
# --- attach_validation with invalid mode --------------------------------
|
|
|
|
Scenario: attach_validation raises ValidationError for invalid mode
|
|
Given a tool registry service with a standard mock repo
|
|
When I attach validation with invalid mode "bogus" via the fallback service
|
|
Then a fallback ValidationError should be raised with message containing "Invalid mode"
|