forked from HAL9000/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
32 lines
1.6 KiB
Gherkin
32 lines
1.6 KiB
Gherkin
@tdd_issue @tdd_issue_988
|
|
Feature: TDD Issue #988 — ReactiveEventBus.emit() swallows exception details
|
|
As a developer debugging a subscriber failure
|
|
I want the exception handler in ReactiveEventBus.emit() to log the full
|
|
exception message and traceback
|
|
So that I can diagnose why a subscriber failed without guessing
|
|
|
|
This test captures bug #988. The exception handler in
|
|
ReactiveEventBus.emit() currently logs only `type(exc).__name__`
|
|
(e.g. "ValueError") without `str(exc)` or `exc_info=True`. When a
|
|
subscriber raises, the log contains no diagnostic detail — no message,
|
|
no traceback, no clue about which input or state caused the failure.
|
|
|
|
The traceback scenario uses `@tdd_expected_fail` because that
|
|
assertion still FAILS while the bug exists. The tag inversion
|
|
mechanism causes CI to report that scenario as passed. Once the
|
|
fix for #988 is merged, the `@tdd_expected_fail` tag must be
|
|
removed so both scenarios run normally.
|
|
|
|
See CONTRIBUTING.md > Bug Fix Workflow > TDD Issue Test Tags.
|
|
|
|
Scenario: Bug #988 — emit() logs exception message when handler raises
|
|
Given a ReactiveEventBus with a handler that raises a ValueError
|
|
When I emit an event that triggers the failing handler
|
|
Then the warning log should contain the exception message text
|
|
|
|
@tdd_expected_fail
|
|
Scenario: Bug #988 — emit() logs traceback via exc_info when handler raises
|
|
Given a ReactiveEventBus with a handler that raises a ValueError
|
|
When I emit an event that triggers the failing handler
|
|
Then the warning log should contain traceback information
|