freemo
ec0b7631d0
CI / lint (push) Successful in 12s
CI / build (push) Successful in 15s
CI / quality (push) Successful in 23s
CI / typecheck (push) Successful in 36s
CI / benchmark-regression (push) Has been skipped
CI / security (push) Successful in 46s
CI / unit_tests (push) Successful in 3m3s
CI / integration_tests (push) Successful in 3m31s
CI / docker (push) Successful in 40s
CI / coverage (push) Successful in 5m34s
CI / benchmark-publish (push) Successful in 19m15s
CI / benchmark-publish (pull_request) Has been skipped
CI / lint (pull_request) Successful in 13s
CI / build (pull_request) Successful in 14s
CI / quality (pull_request) Successful in 17s
CI / security (pull_request) Successful in 34s
CI / typecheck (pull_request) Has been cancelled
CI / unit_tests (pull_request) Has been cancelled
CI / coverage (pull_request) Has been cancelled
CI / benchmark-regression (pull_request) Has been cancelled
CI / integration_tests (pull_request) Has been cancelled
CI / docker (pull_request) Has been cancelled
Renamed src/cleveragents/acp/ to src/cleveragents/a2a/ and all 13 Acp* classes to A2a* per ADR-047 (A2A Standard Adoption). Updated all imports, structlog event names (acp.* → a2a.*), field names (acp_version → a2a_version), and test references across the entire codebase. This is a cosmetic rename only — no behavioral changes. ISSUES CLOSED: #688
83 lines
4.0 KiB
Gherkin
83 lines
4.0 KiB
Gherkin
@phase2 @a2a @coverage-boost
|
|
Feature: A2A clients coverage boost
|
|
As a developer
|
|
I want complete coverage of Protocol default bodies and stub validation branches
|
|
So that all code paths in cleveragents.a2a.clients are exercised
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Protocol default method bodies (the `...` expressions)
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: ServerClient protocol health_check default body executes
|
|
Given a concrete subclass of ServerClient protocol
|
|
When I call health_check on the concrete server client
|
|
Then the call should complete without error
|
|
|
|
Scenario: ServerClient protocol get_version default body executes
|
|
Given a concrete subclass of ServerClient protocol
|
|
When I call get_version on the concrete server client
|
|
Then the call should complete without error
|
|
|
|
Scenario: RemoteExecutionClient protocol execute_plan default body executes
|
|
Given a concrete subclass of RemoteExecutionClient protocol
|
|
When I call execute_plan on the concrete execution client
|
|
Then the call should complete without error
|
|
|
|
Scenario: RemoteExecutionClient protocol get_plan_status default body executes
|
|
Given a concrete subclass of RemoteExecutionClient protocol
|
|
When I call get_plan_status on the concrete execution client
|
|
Then the call should complete without error
|
|
|
|
Scenario: RemoteExecutionClient protocol cancel_plan default body executes
|
|
Given a concrete subclass of RemoteExecutionClient protocol
|
|
When I call cancel_plan on the concrete execution client
|
|
Then the call should complete without error
|
|
|
|
Scenario: AuthClient protocol authenticate default body executes
|
|
Given a concrete subclass of AuthClient protocol
|
|
When I call authenticate on the concrete auth client
|
|
Then the call should complete without error
|
|
|
|
Scenario: AuthClient protocol validate_token default body executes
|
|
Given a concrete subclass of AuthClient protocol
|
|
When I call validate_token on the concrete auth client
|
|
Then the call should complete without error
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Stub validation branches — empty string inputs
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: StubRemoteExecutionClient get_plan_status rejects empty plan_id
|
|
Given a fresh StubRemoteExecutionClient for coverage
|
|
When I call get_plan_status with empty plan_id on the stub
|
|
Then a ValueError should be raised with plan_id validation message
|
|
|
|
Scenario: StubRemoteExecutionClient cancel_plan rejects empty plan_id
|
|
Given a fresh StubRemoteExecutionClient for coverage
|
|
When I call cancel_plan with empty plan_id on the stub
|
|
Then a ValueError should be raised with plan_id validation message
|
|
|
|
Scenario: StubAuthClient validate_token rejects empty token
|
|
Given a fresh StubAuthClient for coverage
|
|
When I call validate_token with empty token on the stub
|
|
Then a ValueError should be raised with token validation message
|
|
|
|
# -----------------------------------------------------------------------
|
|
# Stub validation branches — non-string type inputs
|
|
# -----------------------------------------------------------------------
|
|
|
|
Scenario: StubRemoteExecutionClient get_plan_status rejects non-string plan_id
|
|
Given a fresh StubRemoteExecutionClient for coverage
|
|
When I call get_plan_status with a non-string plan_id on the stub
|
|
Then a ValueError should be raised with plan_id validation message
|
|
|
|
Scenario: StubRemoteExecutionClient cancel_plan rejects non-string plan_id
|
|
Given a fresh StubRemoteExecutionClient for coverage
|
|
When I call cancel_plan with a non-string plan_id on the stub
|
|
Then a ValueError should be raised with plan_id validation message
|
|
|
|
Scenario: StubAuthClient validate_token rejects non-string token
|
|
Given a fresh StubAuthClient for coverage
|
|
When I call validate_token with a non-string token on the stub
|
|
Then a ValueError should be raised with token validation message
|