Files
cleveragents-core/features/tdd_checkpoint_real_rollback.feature
hurui200320 1878998b7a refactor(testing): rename tdd_bug/tdd_bug_N tags to tdd_issue/tdd_issue_N
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
2026-03-27 05:58:35 +00:00

27 lines
1.3 KiB
Gherkin

@tdd_issue @tdd_issue_822
Feature: TDD Issue #822 — checkpoint rollback is simulated, does not execute real git reset
As a developer
I want to verify that CheckpointService.rollback_to_checkpoint()
actually restores file system state via git reset --hard
So that rollback is not merely simulated and the bug is captured
The rollback_to_checkpoint() method constructs a RollbackResult with
checkpoint metadata but skips the real git reset --hard operation.
After rollback, files modified since the checkpoint should be reverted
to their checkpoint-time content. Currently they are not, proving the
bug exists.
Scenario: Rollback restores file content to checkpoint state
Given a temporary git workspace with an initial committed file
And a checkpoint is created from the current commit
And the tracked file is modified after the checkpoint
When I invoke rollback_to_checkpoint targeting the checkpoint
Then the tracked file content should match the checkpoint state
Scenario: Rollback removes files added after the checkpoint
Given a temporary git workspace with an initial committed file
And a checkpoint is created from the current commit
And a new file is added and committed after the checkpoint
When I invoke rollback_to_checkpoint targeting the checkpoint
Then the new file should not exist in the workspace