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
40 lines
2.0 KiB
Gherkin
40 lines
2.0 KiB
Gherkin
@tdd_issue @tdd_issue_821 @mock_only
|
|
Feature: TDD Issue #821 — context tier service has data models but no runtime logic
|
|
As a developer
|
|
I want to verify that ContextTierService automatically promotes, demotes,
|
|
and evicts fragments based on access patterns, staleness, and budget limits
|
|
So that the bug is captured and will be caught by a regression test
|
|
|
|
ContextTierService has well-defined data models for hot/warm/cold tiers
|
|
(ContextTier, TieredFragment, TierBudget) and manual promote()/demote()/
|
|
evict_lru() methods, but NO automatic runtime logic:
|
|
|
|
- get() touches access metadata but never auto-promotes a frequently
|
|
accessed cold/warm fragment to a higher tier.
|
|
- There is no staleness enforcement: no method checks last_accessed
|
|
timestamps and demotes stale hot fragments to warm/cold.
|
|
- store() does not enforce budget limits: storing beyond
|
|
max_tokens_hot does not trigger automatic eviction.
|
|
|
|
These tests assert the expected runtime behaviour and will FAIL until
|
|
the bug is fixed. The @tdd_expected_fail tag inverts the result so
|
|
CI passes.
|
|
|
|
Scenario: Promotion on repeated access moves fragment to a higher tier
|
|
Given a context tier service with default budget
|
|
And a fragment stored in the cold tier
|
|
When I access the fragment 5 times via get
|
|
Then the fragment should have been promoted to warm or hot tier
|
|
|
|
Scenario: Demotion on staleness moves fragment to a lower tier
|
|
Given a context tier service with default budget
|
|
And a fragment stored in the hot tier with a stale last_accessed timestamp
|
|
When I invoke the staleness enforcement runtime
|
|
Then the fragment should have been demoted to warm or cold tier
|
|
|
|
Scenario: Eviction on hot tier budget overflow removes oldest fragment
|
|
Given a context tier service with a small hot tier budget of 100 tokens
|
|
And the hot tier is filled to its token budget limit
|
|
When I store one more fragment in the hot tier
|
|
Then the oldest fragment should have been evicted from the hot tier
|