forked from cleveragents/cleveragents-core
hurui200320
1878998b7a
Rename the TDD tag system from tdd_bug/tdd_bug_<N> to tdd_issue/tdd_issue_<N> across the entire codebase. The tdd_expected_fail tag is unchanged. The TDD expected-failure workflow is not limited to bug fixes — it applies equally to any issue type (features, tasks, refactors). The _bug suffix was misleading and narrowed the perceived scope. The new _issue suffix accurately reflects that the TDD tagging system applies to any Forgejo issue. Changes span 92 files: - features/environment.py: validate_tdd_tags(), should_invert_result(), and apply_tdd_inversion() updated — regex, variables, error messages - robot/tdd_expected_fail_listener.py: _validate_tdd_tags(), _should_invert_result(), start_test(), end_test() updated consistently - 33 Behave .feature files: all @tdd_bug/@tdd_bug_<N> tags renamed - 29 Robot .robot files: all tdd_bug/tdd_bug_<N> tags renamed - 3 Robot fixture files renamed (tdd_bug_alone, tdd_missing_tdd_bug, tdd_expected_fail_missing_bug_n) with content and references updated - Tag validation tests and helpers updated (function names, command dispatch keys, output strings, fixture references) - CONTRIBUTING.md: section renamed from 'TDD Bug Test Tags' to 'TDD Issue Test Tags', all tag references and examples updated - noxfile.py: comment references updated - Step definition files, mock helpers, and benchmark files: docstring references updated ISSUES CLOSED: #965
31 lines
1.5 KiB
Gherkin
31 lines
1.5 KiB
Gherkin
@tdd_issue @tdd_issue_980
|
|
Feature: TDD Issue #980 — skill add cross-process persistence
|
|
As a developer
|
|
I want to verify that `agents skill add --config <file>` persists
|
|
skills across separate CLI process invocations
|
|
So that the bug is captured and will be caught by a regression test
|
|
|
|
Bug #980 reports that skills registered via `agents skill add` in one
|
|
CLI process are not visible when `agents skill list` is run in a
|
|
separate CLI process. Existing persistence tests pass because they
|
|
verify round-trip within the same Python process (creating two
|
|
SkillService instances sharing the same in-memory database).
|
|
|
|
This TDD test captures the regression by using real subprocess
|
|
invocations — the skill is added via one CLI invocation and listed
|
|
via an independent CLI invocation, both sharing the same on-disk
|
|
SQLite database. Originally tagged @tdd_expected_fail while the bug was unfixed;
|
|
tag removed after fix in #980.
|
|
|
|
Scenario: skill add in one process is visible to skill list in another
|
|
Given a cross-process skill persistence environment
|
|
When I add a skill via a CLI subprocess
|
|
And I list skills via a separate CLI subprocess
|
|
Then the cross-process skill list should contain the added skill
|
|
|
|
Scenario: skill add persists config path across processes
|
|
Given a cross-process skill persistence environment
|
|
When I add a skill via a CLI subprocess
|
|
And I show the skill via a separate CLI subprocess
|
|
Then the cross-process skill show output should contain the skill name
|