forked from cleveragents/cleveragents-core
freemo
a808c395f9
Add 53 new .feature files and corresponding step definition files targeting uncovered lines identified in build/coverage.xml. Fix AmbiguousStep conflicts in 7 pre-existing step files by disambiguating step text. New tests cover: ACP clients/facade, actor CLI/config, application container, ACMS service/strategies, async worker, automation profile CLI, autonomy guardrail, bridge, change model, config CLI/service, context service, cross-plan correction, database models, decision service, decomposition clustering/service, discovery handler, langchain chat provider, langgraph nodes, materializers, multi-project service, plan apply/CLI/lifecycle/model/ preflight/resume/service, PostgreSQL analyzer, project CLI/context CLI, provider registry, reactive application/route, repositories, resolver handler, resource registry service, resume model, retry patterns, sandbox protocol, server CLI, skill CLI/service, skills registry, subplan execution/service, system CLI, UKO loader, UoW, and YAML template engine. Closes #645
83 lines
4.0 KiB
Gherkin
83 lines
4.0 KiB
Gherkin
@phase2 @acp @coverage-boost
|
|
Feature: ACP 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.acp.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
|