Files
cleveragents-core/features/a2a_facade_optional_param_validation.feature
HAL9000 893debfeaf fix(a2a): add input validation for optional parameters in facade handlers
- Added input validation for namespace parameter in _handle_registry_list_tools in src/cleveragents/a2a/facade.py: If provided, must be a non-empty string; empty strings raise ValueError; non-string types raise TypeError
- Added input validation for type_name parameter in _handle_registry_list_resources in src/cleveragents/a2a/facade.py: If provided, must be a non-empty string; empty strings raise ValueError; non-string types raise TypeError
- Added input validation for arguments parameter in _handle_plan_create in src/cleveragents/a2a/facade.py: If provided, must be a dict; non-dict types raise TypeError
- Added input validation for created_by parameter in _handle_plan_create in src/cleveragents/a2a/facade.py: If provided, must be a non-empty string; empty strings raise ValueError; non-string types raise TypeError
- Added BDD feature file features/a2a_facade_optional_param_validation.feature with 17 scenarios covering all validation paths
- Added step definitions features/steps/a2a_facade_optional_param_validation_steps.py

ISSUES CLOSED: #9059
2026-06-02 23:33:52 -04:00

123 lines
6.8 KiB
Gherkin

Feature: A2A facade optional parameter validation
As a developer using the A2A local facade
I want optional parameters to be validated before being passed to services
So that invalid inputs are rejected early with clear error messages
# -------------------------------------------------------------------
# _handle_registry_list_tools namespace validation
# -------------------------------------------------------------------
Scenario: list_tools with valid namespace succeeds
Given an opt-val facade with a mock ToolRegistry
When I dispatch opt-val operation "registry.list_tools" with params {"namespace": "local"}
Then the opt-val response status should be "ok"
And the opt-val response data should contain key "tools"
Scenario: list_tools with None namespace succeeds
Given an opt-val facade with a mock ToolRegistry
When I dispatch opt-val operation "registry.list_tools" with params {}
Then the opt-val response status should be "ok"
And the opt-val response data should contain key "tools"
Scenario: list_tools with empty string namespace returns error
Given an opt-val facade with a mock ToolRegistry
When I dispatch opt-val operation "registry.list_tools" with params {"namespace": ""}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "namespace must be a non-empty string"
Scenario: list_tools with non-string namespace returns error
Given an opt-val facade with a mock ToolRegistry
When I dispatch opt-val operation "registry.list_tools" with params {"namespace": 42}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "namespace must be a string or None"
Scenario: list_tools with no registry returns empty tools list
Given an opt-val facade with no services
When I dispatch opt-val operation "registry.list_tools" with params {"namespace": "local"}
Then the opt-val response status should be "ok"
And the opt-val response data should contain key "tools"
# -------------------------------------------------------------------
# _handle_registry_list_resources — type_name validation
# -------------------------------------------------------------------
Scenario: list_resources with valid type_name succeeds
Given an opt-val facade with a mock ResourceRegistryService
When I dispatch opt-val operation "registry.list_resources" with params {"type_name": "git-checkout"}
Then the opt-val response status should be "ok"
And the opt-val response data should contain key "resources"
Scenario: list_resources with None type_name succeeds
Given an opt-val facade with a mock ResourceRegistryService
When I dispatch opt-val operation "registry.list_resources" with params {}
Then the opt-val response status should be "ok"
And the opt-val response data should contain key "resources"
Scenario: list_resources with empty string type_name returns error
Given an opt-val facade with a mock ResourceRegistryService
When I dispatch opt-val operation "registry.list_resources" with params {"type_name": ""}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "type_name must be a non-empty string"
Scenario: list_resources with non-string type_name returns error
Given an opt-val facade with a mock ResourceRegistryService
When I dispatch opt-val operation "registry.list_resources" with params {"type_name": 99}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "type_name must be a string or None"
Scenario: list_resources with no service returns empty resources list
Given an opt-val facade with no services
When I dispatch opt-val operation "registry.list_resources" with params {"type_name": "git-checkout"}
Then the opt-val response status should be "ok"
And the opt-val response data should contain key "resources"
# -------------------------------------------------------------------
# _handle_plan_create — arguments validation
# -------------------------------------------------------------------
Scenario: plan.create with valid dict arguments succeeds
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "arguments": {"target": "all"}}
Then the opt-val response status should be "ok"
And the opt-val response data key "status" should equal "created"
Scenario: plan.create with None arguments succeeds
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build"}
Then the opt-val response status should be "ok"
And the opt-val response data key "status" should equal "created"
Scenario: plan.create with non-dict arguments returns error
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "arguments": "not-a-dict"}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "arguments must be a dict or None"
# -------------------------------------------------------------------
# _handle_plan_create — created_by validation
# -------------------------------------------------------------------
Scenario: plan.create with valid created_by succeeds
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "created_by": "alice"}
Then the opt-val response status should be "ok"
And the opt-val response data key "status" should equal "created"
Scenario: plan.create with None created_by succeeds
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build"}
Then the opt-val response status should be "ok"
And the opt-val response data key "status" should equal "created"
Scenario: plan.create with empty string created_by returns error
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "created_by": ""}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "created_by must be a non-empty string"
Scenario: plan.create with non-string created_by returns error
Given an opt-val facade with a mock PlanLifecycleService
When I dispatch opt-val operation "plan.create" with params {"action_name": "build", "created_by": 123}
Then the opt-val response status should be "error"
And the opt-val response error message should contain "created_by must be a string or None"