🐛 Bug Report: Background failures generate event.test.failed instead of event.test.skipped for subsequent tests
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- javascript
- 领域
- testing
调研方向
从 Gherkin Background 的失败路径以及 event.test.before、event.test.failed、event.test.skipped 和 event.test.after 入口点开始。分别复现常规 Scenario 情况和 --grep Scenario Outline 情况,并与 CodeceptJS 3.6.7 的行为进行比较。当未选中的测试或后续测试收到预期的 skipped 事件且没有重复的失败报告时,即完成。
由索引模型根据 Issue 内容生成。
描述
Description
Since CodeceptJS 3.7.5, when a Background hook fails in a Gherkin feature, all tests in the same Feature file receive event.test.failed events instead of event.test.skipped. This is a breaking change from version 3.6.7 that significantly complicates result reporting and event handling.
Core Issue: When Background fails, CodeceptJS triggers event.test.failed for:
- Tests that failed on Background ✓ (expected)
- Subsequent tests marked as failed without ability to trigger
event.test.skippedorevent.test.afterproperly - Tests in the same suite file that were never meant to run (not selected by
--grep)
This forces custom reporting systems to manually filter and track which tests actually executed before sending results. Previously, simple event handlers worked fine - now complex workarounds are required.
Expected Behavior (CodeceptJS 3.6.7)
When a Background fails:
- First test: receives
event.test.failed - Subsequent tests: receive
event.test.skipped
// Clean event handling in 3.6.7
event.dispatcher.on(event.test.skipped, (test) => {
// This worked for all tests after first Background failure ✅
sendSkippedReport(test)
})
Actual Behavior (CodeceptJS 3.7.5+)
When a Background fails:
- All tests: receive
event.test.failed event.test.skippednever fires
// Complex workaround needed in 3.7.5+
let firstBackgroundFailure = true
event.dispatcher.on(event.test.failed, (test, error) => {
const isBackgroundFailure = test.ctx?.test?.originalTitle?.startsWith('"before each" hook:')
// Manually handle what should be skipped tests
if (isBackgroundFailure && !firstBackgroundFailure) {
// Have to manually convert failed → skipped ❌
sendSkippedReport(test)
return
}
if (isBackgroundFailure) {
firstBackgroundFailure = false
}
})
Problems with Current Behavior
1. Semantic Incorrectness
Tests that never started executing (only Background failed) are marked as failed. Semantically, a test that didn't run should be skipped, not failed.
2. Breaking Change Without Clear Benefits
The change from 3.6.7 to 3.7.5 broke existing event handlers without providing clear advantages. All code relying on event.test.skipped for Background failures stopped working.
3. Event Generation Inconsistency
For regular Scenarios:
When Background fails on first test, subsequent tests don't trigger event.test.after, making it impossible to send reports for them:
Feature: Test
Background:
Given failing step
Scenario: Test 1 # Background fails here
Then something
Scenario: Test 2 # event.test.after doesn't process this properly
Then something
For Scenario Outline (running by tests, not by suites):
When using --grep to run a single test, CodeceptJS generates event.test.failed for all examples in the suite, even those from different Scenario Outlines that weren't selected:
Scenario Outline: Test
# Background fails here
Examples:
| case |
| A | # Not selected by --grep, different Scenario Outline
| B | # Selected by --grep ← only this should run
| C | # Not selected by --grep, different Scenario Outline
Result: All three tests (A, B, C) receive event.test.failed, even though only B was selected to run.
Key issue: event.test.before fires only for filtered tests, but event.test.failed and event.test.after fire for ALL examples, making it impossible to distinguish which tests actually ran.
4. Complex Workarounds Required
To maintain reasonable behavior, we now need:
- Track which tests actually started (
event.test.before) - Track first vs subsequent Background failures
- Manually convert
failed→skippedinevent.test.failedhandler - Filter out events for tests that never ran
- Initialize tracking in
event.test.failedfor tests where Background failed beforeevent.test.beforecould fire
5. Report Analysis Difficulties
- Before: "1 failed, 5 skipped" = clear that Background failed
- After: "6 failed" = looks like 6 different failures, unclear what happened
6. Multiple Events for Same Test
When Background retry mechanism triggers (e.g., with retryFailedStep plugin), the same test receives event.test.failed multiple times, leading to duplicate reports if not handled carefully.
Steps to Reproduce
Case 1: Regular Scenarios
- Create a feature file with Background and multiple Scenarios
- Make Background fail
- Observe that second test doesn't properly trigger reporting in
event.test.after
Feature: Test
Background:
Given failing step # ← Fails here
Scenario: Test 1
Then something
Scenario: Test 2 # This won't be properly reported
Then something
Case 2: Scenario Outline with --grep
- Create a Scenario Outline with multiple examples
- Run single test with
--grep @TAG-B - Observe that ALL examples receive
event.test.failed, not just the filtered one
Feature: Test
Background:
Given failing step # ← Fails here
Scenario Outline: Test
Then something
Examples:
| case | tag |
| A | @TAG-A |
| B | @TAG-B | # Only this is selected
| C | @TAG-C |
Expected: Only B receives events
Actual: A, B, and C all receive event.test.failed
Environment
- CodeceptJS version: 3.7.5+
- Node version: 22.4.0
- Helpers: WebDriver, Gherkin
Proposed Solution
Option 1 (Preferred): Revert to 3.6.7 behavior
- First test with Background failure →
event.test.failed - Subsequent tests →
event.test.skipped
Option 2: Add new event type
event.test.failedInBackgroundor similar- Allows distinguishing Background failures from test failures
- Maintains backward compatibility
Option 3: Configuration option
// codecept.conf.js
gherkin: {
backgroundFailureBehavior: 'skip' // or 'fail'
}
Impact
This breaking change affects:
- Custom reporting plugins
- CI/CD result analysis
- Test retry logic
- Statistics collection
- Any code relying on
event.test.skipped
References
Comment in our codebase acknowledging this breaking change:
// CodeceptJS 3.6.7 → 3.7.5: tests failing in Background are now 'failed' instead of 'skipped'
// Handle Background failures as skipped to maintain compatibility
Would it be possible to either revert this change or provide a configuration option to restore the 3.6.7 behavior? The current implementation significantly complicates result handling and doesn't align with the semantic meaning of "skipped" vs "failed".
- 主要语言
- JavaScript
- 星标
- 4.2k
- 派生
- 756
- 平均合并
- 2 天 9 小时
- 30 天内合并 PR
- 16
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
codeceptjs/CodeceptJS 的其他 Issue
-
stale
难度 2/5 1-3 小时 新手友好度 72/100
codeceptjs/CodeceptJS#5420 · 1 条评论 ·
-
stale
难度 2/5 1-3 小时 新手友好度 76/100
codeceptjs/CodeceptJS#5358 · 1 条评论 ·
-
stale
难度 2/5 1-3 小时 新手友好度 78/100
codeceptjs/CodeceptJS#4958 · 10 条评论 · 2 个 reaction ·
-
stale
难度 1/5 1 小时以内 新手友好度 72/100
codeceptjs/CodeceptJS#4778 · 3 条评论 ·
-
stale
难度 4/5 3-5 天 新手友好度 38/100
codeceptjs/CodeceptJS#5618 · 1 条评论 ·
查看 codeceptjs/CodeceptJS 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
avniproject/avni-client#2135 ·
-
enhancement
难度 2/5 1-3 小时 新手友好度 70/100
babalae/bettergi-scripts-list#3674 ·
-
A-Release-Notes C-Editing D-Modest S-Ready-For-Implementation
难度 2/5 1-3 小时 新手友好度 72/100
bevyengine/bevy-website#2595 ·
-
ecosystem wording
难度 1/5 1 小时以内 新手友好度 90/100
matrix-org/matrix.org#3649 ·
-
难度 2/5 1-3 小时 新手友好度 88/100
vadimdemedes/ink#1029 ·