hurui200320
2005b8ef82
CI / push-validation (push) Successful in 18s
CI / build (push) Successful in 19s
CI / helm (push) Successful in 24s
CI / lint (push) Successful in 29s
CI / security (push) Successful in 1m11s
CI / e2e_tests (push) Successful in 2m56s
CI / quality (push) Successful in 3m40s
CI / typecheck (push) Successful in 3m59s
CI / integration_tests (push) Successful in 4m3s
CI / unit_tests (push) Successful in 4m55s
CI / docker (push) Successful in 10s
CI / coverage (push) Successful in 10m44s
CI / status-check (push) Successful in 1s
CI / benchmark-regression (push) Has been skipped
CI / benchmark-publish (push) Successful in 1h13m28s
## Summary Replaces all 234 bare `@skip` occurrences across 82 Behave feature files with the correct TDD issue-capture tagging system described in CONTRIBUTING.md § Bug Fix Workflow. Previously, the noxfile ran Behave with `--tags=not @skip`, silently excluding all `@skip`-tagged scenarios from every CI run. These tests never ran, never inverted results via the `@tdd_expected_fail` mechanism, and never contributed to coverage — defeating the purpose of TDD issue-capture testing. Every `@skip` occurrence had a commented-out hint line immediately above it showing the intended proper tags (e.g., `# @tdd_issue @tdd_issue_4272 @tdd_expected_fail @skip`), confirming they were all intended for conversion. ## Changes ### Mechanical conversion (234 replacements across 82 files) - Extracted the proper TDD tags from the comment hint above each `@skip` line, removed `@skip` from the tag set, and replaced the `@skip` line with those tags. - Removed the now-redundant comment hint lines alongside each replacement. ### Bug-fixed scenarios — `@tdd_expected_fail` removed (84 scenarios) - After conversion, ran `nox -s unit_tests` to identify which newly-enabled `@tdd_expected_fail` scenarios now **pass** (their referenced bugs have already been fixed). Removed `@tdd_expected_fail` from those 84 scenarios and their corresponding feature-level tags, leaving only the permanent `@tdd_issue @tdd_issue_<N>` regression-guard tags. - Affected features include: `tdd_tool_runner_env_precedence`, `tdd_automation_profile_session_leak`, `tls_certificate_check`, `project_create_persist`, `resource_type_bootstrap_*`, and 18 others. ### Noxfile cleanup - Removed all four `--tags=not @skip` arguments from `noxfile.py` (unit_tests and coverage sessions). With zero `@skip` tags remaining in the codebase, this filter was dead code and its presence would mislead future maintainers into thinking `@skip` is still a supported escape mechanism. ### Regression guard files - Split the regression guards into two focused files: - `tdd_regression_guards_exec_env.feature` for bug #4281 (exec-env precedence) - `tdd_regression_guards_session_list.feature` for bug #4271 (session list summary) - Each file carries only its own `@tdd_issue` tags at the feature level, avoiding cross-contamination via Behave tag inheritance. The `Background` step (`session-list-summary mock`) only appears in the session-list file where it is actually needed. ### Duplicate tag cleanup - Removed duplicate `@tdd_issue @tdd_issue_4287` tag lines in `tdd_skill_add_regression.feature` (lines 20 and 29). ### Inline comment for retained `@tdd_expected_fail` - Added inline comment in `ci_workflow_validation.feature:134` explaining why this specific #4227 scenario retains `@tdd_expected_fail` despite #4227 being closed (CI YAML does not encode threshold as a machine-readable value). ### Known edge cases — `@tdd_expected_fail` retained (closed issues, fix on master, scenarios still fail) The following issues are **closed** and their fixes **are on master**, but the specific test assertions still fail because the fixes address other aspects of the bugs. The `@tdd_expected_fail` tags are functionally correct and must remain until the specific scenario assertions pass: - `tdd_exec_env_resolution_precedence.feature` — bug #1080 (closed 2026-03-31). The precedence-level-2-vs-4 scenario still fails. - `session_list_summary_dedup.feature` — bug #3046 (closed 2026-04-05). The dedup-consistency scenarios still fail. - `actor_add_update_enforcement.feature` — bug #2609 (closed 2026-04-05). The enforcement scenarios still fail. - `ci_workflow_validation.feature:134` — #4227 (closed 2026-04-08). The CI YAML threshold assertion still fails. ## Verification - `grep -r "@skip" features/ --include="*.feature"` → **zero results** ✓ - `grep -n "tags=not @skip" noxfile.py` → **zero results** ✓ - `nox -s unit_tests` → **629 features passed, 0 failed** ✓ (up from ~545 before this PR) - CI all green (coverage ≥ 97%) ✓ - Integration tests (Robot Framework) do not use `@skip` — confirmed no action needed ✓ - E2E tests (Robot Framework) do not use `@skip` — confirmed no action needed ✓ - `CHANGELOG.md` updated with entry for this change ✓ - `CONTRIBUTORS.md` — Rui Hu already listed ✓ ## Issues Addressed Closes #7025 Co-authored-by: CleverThis <hal9000@cleverthis.com> Reviewed-on: #7221 Reviewed-by: HAL 9000 <HAL9000@cleverthis.com> Reviewed-by: HAL9001 <hal9001@cleverthis.com> Co-authored-by: Rui Hu <rui.hu@cleverthis.com> Co-committed-by: Rui Hu <rui.hu@cleverthis.com>
245 lines
10 KiB
Gherkin
245 lines
10 KiB
Gherkin
Feature: Resource CLI error path coverage
|
|
As a developer
|
|
I want the resource CLI error handling paths thoroughly tested
|
|
So that resource.py has high code coverage
|
|
|
|
Background:
|
|
Given a fresh in-memory resource registry
|
|
|
|
# ---- type_add error paths ----
|
|
|
|
Scenario: type add with --update flag on existing type
|
|
Given built-in types are bootstrapped
|
|
Given a valid custom resource type YAML file
|
|
And I run resource type add with the config file
|
|
When I run resource type add with the config file using update flag
|
|
Then the resource command should fail
|
|
And the resource output should contain "already exists"
|
|
|
|
Scenario: type add with non-existent config triggers FileNotFoundError
|
|
When I run resource type add with a nonexistent config file
|
|
Then the resource command should fail
|
|
And the resource output should contain "not found"
|
|
|
|
Scenario: type add with validation error
|
|
Given a custom resource type YAML file with invalid schema
|
|
When I run resource type add with the config file
|
|
Then the resource command should fail
|
|
|
|
Scenario: type add with non-rich format
|
|
Given a valid custom resource type YAML file
|
|
When I run resource type add with the config file and format "json"
|
|
Then the resource output should be valid JSON
|
|
|
|
# ---- type_remove error paths ----
|
|
|
|
Scenario: type remove confirmation prompt aborted
|
|
Given a valid custom resource type YAML file
|
|
And I run resource type add with the config file
|
|
When I run resource type remove "test/custom-type" without yes flag
|
|
Then the resource command should fail
|
|
|
|
Scenario: type remove non-existent type raises NotFoundError
|
|
When I run resource type remove "nonexistent/type" with yes flag
|
|
Then the resource command should fail
|
|
And the resource output should contain "not found"
|
|
|
|
Scenario: type remove with resources referencing custom type
|
|
Given a valid custom resource type YAML file
|
|
And I run resource type add with the config file
|
|
And I add a resource referencing custom type "test/custom-type"
|
|
When I run resource type remove "test/custom-type" with yes flag
|
|
Then the resource command should fail
|
|
And the resource output should contain "Cannot remove"
|
|
|
|
# ---- type_show error paths ----
|
|
|
|
Scenario: type show non-rich format
|
|
Given built-in types are bootstrapped
|
|
When I run resource type show "git-checkout" using format "yaml"
|
|
Then the resource output should contain "name"
|
|
|
|
Scenario: type show with plain format
|
|
Given built-in types are bootstrapped
|
|
When I run resource type show "git-checkout" using format "plain"
|
|
Then the resource output should contain "git-checkout"
|
|
|
|
# ---- type_list non-rich format ----
|
|
|
|
Scenario: type list with yaml format
|
|
Given built-in types are bootstrapped
|
|
When I run resource type list with format "yaml"
|
|
Then the resource output should contain "name"
|
|
|
|
Scenario: type list with plain format
|
|
Given built-in types are bootstrapped
|
|
When I run resource type list with format "plain"
|
|
Then the resource output should contain "git-checkout"
|
|
|
|
# ---- resource_add error paths ----
|
|
|
|
Scenario: resource add with non-rich format
|
|
Given built-in types are bootstrapped
|
|
When I run resource add formatted as "json" type "git-checkout" name "local/fmt-test" path "/tmp/fmt"
|
|
Then the resource output should be valid JSON
|
|
|
|
Scenario: resource add with description and branch
|
|
Given built-in types are bootstrapped
|
|
When I run resource add with extras type "git-checkout" name "local/branch-test" path "/tmp/b" branch "main" description "My repo"
|
|
Then the resource output should contain "local/branch-test"
|
|
|
|
Scenario: resource add with validation error for non-existent type
|
|
When I run resource add "nonexistent" "local/test" with path "/tmp"
|
|
Then the resource command should fail
|
|
And the resource output should contain "not found"
|
|
|
|
# ---- resource_list error paths ----
|
|
|
|
Scenario: resource list with non-rich format
|
|
Given built-in types are bootstrapped
|
|
And I run resource add "git-checkout" "local/list-fmt" with path "/tmp/lfmt"
|
|
When I run resource list with format "json"
|
|
Then the resource output should be valid JSON
|
|
|
|
Scenario: resource list with long description truncation
|
|
Given built-in types are bootstrapped
|
|
And I add a resource with a long description
|
|
When I run resource list
|
|
Then the resource output should contain "local/long-desc"
|
|
|
|
# ---- resource_show error paths ----
|
|
|
|
Scenario: resource show with non-rich format
|
|
Given built-in types are bootstrapped
|
|
And I run resource add "git-checkout" "local/show-fmt" with path "/tmp/sfmt"
|
|
When I run resource show "local/show-fmt" using format "json"
|
|
Then the resource output should be valid JSON
|
|
|
|
Scenario: resource show with empty properties
|
|
Given built-in types are bootstrapped
|
|
And I run resource add "git-checkout" "local/no-props" with path "/tmp/np"
|
|
When I run resource show "local/no-props" using default format
|
|
Then the resource output should contain "local/no-props"
|
|
|
|
# ---- resource_remove error paths ----
|
|
|
|
Scenario: resource remove confirmation prompt aborted
|
|
Given built-in types are bootstrapped
|
|
And I run resource add "git-checkout" "local/no-confirm" with path "/tmp/nc"
|
|
When I run resource remove "local/no-confirm" without yes flag
|
|
Then the resource command should fail
|
|
|
|
Scenario: resource remove non-existent resource raises NotFoundError
|
|
When I run resource remove "nonexistent" with yes flag
|
|
Then the resource command should fail
|
|
And the resource output should contain "not found"
|
|
|
|
# ---- CleverAgentsError catch-all paths ----
|
|
|
|
Scenario: type list raises CleverAgentsError
|
|
Given a service that raises CleverAgentsError on list_types
|
|
When I run resource type list
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: type show raises CleverAgentsError
|
|
Given a service that raises CleverAgentsError on show_type
|
|
When I run resource type show "anything" using default format
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: type add raises CleverAgentsError
|
|
Given a valid custom resource type YAML file
|
|
And a service that raises CleverAgentsError on register_type
|
|
When I run resource type add with the config file
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: type remove raises CleverAgentsError
|
|
Given a service that raises CleverAgentsError on show_type
|
|
When I run resource type remove "anything" with yes flag
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: resource add ValidationError
|
|
Given a service that raises ValidationError on register_resource
|
|
When I run resource add "git-checkout" "local/test" with path "/tmp"
|
|
Then the resource command should fail
|
|
And the resource output should contain "Validation error"
|
|
|
|
Scenario: resource add CleverAgentsError
|
|
Given a service that raises CleverAgentsError on register_resource
|
|
When I run resource add "git-checkout" "local/test" with path "/tmp"
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: resource list raises CleverAgentsError
|
|
Given a service that raises CleverAgentsError on list_resources
|
|
When I run resource list
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: resource show raises CleverAgentsError
|
|
Given a service that raises CleverAgentsError on show_resource
|
|
When I run resource show "anything" using default format
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
Scenario: resource remove raises CleverAgentsError
|
|
Given a service that raises CleverAgentsError on show_resource
|
|
When I run resource remove "anything" with yes flag
|
|
Then the resource command should fail
|
|
And the resource output should contain "Error"
|
|
|
|
# ---- Additional path coverage ----
|
|
|
|
Scenario: type show with rich format shows panel for type without cli_args
|
|
Given a type without cli_args is registered
|
|
When I run resource type show "test/no-args" using default format
|
|
Then the resource output should contain "test/no-args"
|
|
|
|
Scenario: resource show with truly empty properties
|
|
Given built-in types are bootstrapped
|
|
And I add a resource with empty properties
|
|
When I run resource show "local/empty-props" using default format
|
|
Then the resource output should contain "local/empty-props"
|
|
And the resource output should contain "none"
|
|
|
|
Scenario: resource remove succeeds with session delete
|
|
Given built-in types are bootstrapped
|
|
And I run resource add "git-checkout" "local/to-delete" with path "/tmp/del"
|
|
When I run resource remove "local/to-delete" with yes flag
|
|
Then the resource output should contain "Removed resource"
|
|
|
|
Scenario: type add FileNotFoundError catch
|
|
When I run resource type add with path to missing file
|
|
Then the resource command should fail
|
|
And the resource output should contain "not found"
|
|
|
|
# ---- --clone-into flag coverage ----
|
|
|
|
@tdd_issue @tdd_issue_4262 @tdd_expected_fail
|
|
Scenario: resource add container-instance with --clone-into stores clone_into property
|
|
Given built-in types are bootstrapped
|
|
When I run resource add "container-instance" "local/clone-test" with clone-into "https://github.com/acme/api.git:/workspace"
|
|
Then the resource output should contain "local/clone-test"
|
|
And the resource output should contain "Added resource"
|
|
|
|
Scenario: resource add with --clone-into on non-container type fails
|
|
Given built-in types are bootstrapped
|
|
When I run resource add "git-checkout" "local/bad-clone" with clone-into "https://github.com/acme/api.git:/workspace"
|
|
Then the resource command should fail
|
|
And the resource output should contain "Validation error"
|
|
|
|
Scenario: resource add with --clone-into in invalid format fails
|
|
Given built-in types are bootstrapped
|
|
When I run resource add "container-instance" "local/bad-fmt" with clone-into "no-colon-separator"
|
|
Then the resource command should fail
|
|
And the resource output should contain "Validation error"
|
|
|
|
Scenario: resource add with --clone-into missing path segment fails
|
|
Given built-in types are bootstrapped
|
|
When I run resource add "container-instance" "local/bad-path" with clone-into "https://github.com/acme/api.git:"
|
|
Then the resource command should fail
|
|
And the resource output should contain "Validation error"
|