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
38 lines
1.9 KiB
Gherkin
38 lines
1.9 KiB
Gherkin
@tdd_issue @tdd_issue_658
|
|
Feature: TDD Issue #658 — E2E verification suites use mocks instead of real system
|
|
As a developer
|
|
I want to verify that M1-M6 E2E verification suites exercise at least one
|
|
real (non-mocked) CLI code path via subprocess invocation
|
|
So that integration failures in DI wiring, database, and process-level
|
|
behavior are detectable by the E2E test suites
|
|
|
|
The root cause is that all 21 CLI-facing tests in the M1-M6 E2E helper
|
|
files use ``unittest.mock.patch`` to replace service factories with
|
|
``MagicMock`` objects and invoke the CLI via Typer's in-process
|
|
``CliRunner`` instead of ``subprocess.run``. This means:
|
|
|
|
- DI wiring bugs (e.g. the ``container.db()`` AttributeError in #554,
|
|
#570) are invisible to the E2E suites.
|
|
- Database schema/migration issues are invisible.
|
|
- Process-level behavior (exit codes, environment variables, Rich
|
|
console routing) is never tested.
|
|
|
|
The 35 remaining tests are pure domain/service-level tests that never
|
|
invoke the CLI at all — they are legitimate unit/integration tests but
|
|
should not be labeled "E2E verification."
|
|
|
|
Background:
|
|
Given the M1-M6 E2E verification helper files exist for e2e-mock-audit
|
|
|
|
Scenario: At least one CLI-facing E2E test invokes the real CLI via subprocess
|
|
When I analyze mock and subprocess usage in M1-M6 helpers for e2e-mock-audit
|
|
Then at least one CLI-facing test should use subprocess instead of CliRunner for e2e-mock-audit
|
|
|
|
Scenario: At least one CLI-facing E2E test exercises the real service layer
|
|
When I analyze mock and subprocess usage in M1-M6 helpers for e2e-mock-audit
|
|
Then at least one CLI-facing test should not mock the service factory for e2e-mock-audit
|
|
|
|
Scenario: No E2E suite has 100% mocked CLI tests
|
|
When I analyze mock and subprocess usage per suite for e2e-mock-audit
|
|
Then every suite with CLI tests should have at least one unmocked test for e2e-mock-audit
|