hurui200320
1878998b7a
CI / benchmark-publish (pull_request) Has been skipped
CI / build (pull_request) Successful in 25s
CI / lint (pull_request) Successful in 3m19s
CI / typecheck (pull_request) Successful in 3m56s
CI / security (pull_request) Successful in 4m6s
CI / quality (pull_request) Successful in 4m10s
CI / integration_tests (pull_request) Successful in 7m20s
CI / unit_tests (pull_request) Successful in 7m44s
CI / docker (pull_request) Successful in 1m8s
CI / e2e_tests (pull_request) Successful in 13m1s
CI / coverage (pull_request) Successful in 12m25s
CI / status-check (pull_request) Successful in 1s
CI / build (push) Successful in 26s
CI / lint (push) Successful in 3m31s
CI / quality (push) Successful in 3m40s
CI / typecheck (push) Successful in 3m57s
CI / benchmark-regression (push) Has been skipped
CI / security (push) Successful in 4m1s
CI / integration_tests (push) Successful in 8m55s
CI / unit_tests (push) Successful in 9m14s
CI / docker (push) Successful in 9s
CI / e2e_tests (push) Successful in 11m42s
CI / coverage (push) Successful in 11m37s
CI / status-check (push) Successful in 4s
CI / benchmark-publish (push) Successful in 29m25s
CI / benchmark-regression (pull_request) Successful in 54m8s
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
49 lines
3.0 KiB
Gherkin
49 lines
3.0 KiB
Gherkin
# TDD issue-capture test for bug #1022 — InvariantService in-memory storage only.
|
|
#
|
|
# InvariantService stores invariants in an in-memory dict (self._invariants)
|
|
# with no database persistence layer. Each CLI invocation spawns a fresh
|
|
# process with a new InvariantService() instance, so all invariants added in
|
|
# one invocation are lost when the process exits.
|
|
#
|
|
# These scenarios prove the bug exists by simulating separate CLI invocations
|
|
# (fresh InvariantService instances) and asserting that data added in one
|
|
# invocation is visible in the next. They FAIL until the bug is fixed.
|
|
# The @tdd_expected_fail tag inverts the result so CI passes.
|
|
#
|
|
# See: https://git.cleverthis.com/cleveragents/cleveragents-core/issues/1022
|
|
|
|
@tdd_expected_fail @tdd_issue @tdd_issue_1022 @mock_only
|
|
Feature: TDD Issue #1022 — InvariantService invariants lost across process restarts
|
|
As a developer using the agents CLI
|
|
I want invariants added via "agents invariant add" to persist across CLI invocations
|
|
So that "agents invariant list" in a subsequent invocation returns previously added invariants
|
|
|
|
InvariantService uses in-memory dict storage only. Each CLI invocation
|
|
creates a fresh InvariantService() instance, so invariants are lost when
|
|
the process exits. These tests simulate separate process invocations by
|
|
creating fresh service instances and verifying cross-instance data visibility.
|
|
|
|
Scenario: Invariant added in one service instance is visible in a fresh instance
|
|
Given I add a project invariant "All APIs must validate auth tokens" to project "local/api-service" via invariant service instance A
|
|
When I create a fresh invariant service instance B
|
|
And I list project invariants for "local/api-service" via instance B
|
|
Then the invariant list from instance B should contain "All APIs must validate auth tokens"
|
|
|
|
Scenario: Global invariant persists across simulated process restarts
|
|
Given I add a global invariant "Never delete production data" via invariant service instance A
|
|
When I create a fresh invariant service instance B
|
|
And I list global invariants via instance B
|
|
Then the invariant list from instance B should contain "Never delete production data"
|
|
|
|
Scenario: Invariant added via CLI add is visible via CLI list in a new invocation
|
|
Given I invoke invariant add via CLI with "--project local/webapp" and text "All changes need tests" using service invocation 1
|
|
When I invoke invariant list via CLI with "--project local/webapp" using service invocation 2
|
|
Then the CLI list output from invocation 2 should contain "All changes need tests"
|
|
|
|
Scenario: Invariant soft-deleted in a fresh instance after being added in another
|
|
Given I add a project invariant "Temporary constraint" to project "local/temp" via invariant service instance A
|
|
And I capture the invariant ID from instance A
|
|
When I create a fresh invariant service instance B
|
|
And I attempt to remove the captured invariant ID via instance B
|
|
Then the remove operation via instance B should succeed without NotFoundError
|