Test based on `findByText` assertion fails after 551ms, despite default timeout being 1000ms
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- javascript, react, typescript
- 领域
- testing-qa
调研方向
从提供的 screen.findByText 断言以及列出的 @testing-library/react 16.3.0、Vitest 3.2.4 和 jsdom 26.1.0 版本开始。以链接的 findBy 文档和之前的 issue 作为上下文，调查该失败是否达到了文档所述的 1000ms 超时，或者 Vitest 报告的持续时间是否不准确。完成的标准是确定间歇性提前失败的来源，或记录其属于外部因素。
由索引模型根据 Issue 内容生成。
描述
@testing-library/reactversion: 16.3.0- Testing Framework and version: Vitest 3.2.4
- DOM Environment: jsdom 26.1.0
Relevant code or config:
expect(
await screen.findByText(
"text which is supposed to be found after loading state is passed",
),
).toBeInTheDocument();
What you did:
Ran a test which failed on this assertion. Only sometimes. Typically in CI (Github Actions).
What happened:
× path/to/my.test.tsx > x > shows expected content 551ms
→ expect(element).toBeInTheDocument()
element could not be found in the document
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
FAIL path/to/my.test.tsx > x > shows expected content
Error: expect(element).toBeInTheDocument()
element could not be found in the document
Reproduction:
Does not reproduce easily. Is flaky. Trying to understand if there is some misunderstanding in how things are supposed to work.
Problem description:
When running a test based on findBy, we sometimes find them to be flaky. It is sometimes resolved by using waitForElementToBeRemoved on the previous state, but that just adds another possible race condition, and also tends to be flaky.
I expect the test to run for at least 1000ms (as per findBy logic documented here), but sometimes find that the test fails much sooner (after 551 ms in the example above).
Suggested solution:
I'm trying to deduce a cause here for further investigation.
- Is
findByresolving sooner than expected? If yes, it seems like a problem internal to the library, possibly https://github.com/testing-library/react-testing-library/issues/865? - Is the (vitest) reported time unreliable, and we may have hit the 1000ms timeout despite 551ms being reported? If so, maybe extending the default timeout could be beneficial, even though hundreds of similar tests tend to pass every time, so it seems odd.
Overall, this seems like a strange problem, and I'm not expecting a straight-forward fix, but would like you to know about it, and would be grateful for any pointers on how to analyze further.
- 主要语言
- JavaScript
- 星标
- 19.7k
- 派生
- 1.2k
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
testing-library/react-testing-library 的其他 Issue
-
fireEvent.select does not wrap its automatic native focus in act可能已有人在做 @sergioperezcheco 于 7 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
-
bug: calling configure() without reactStrictMode resets it to undefined, silently disabling strict mode可能重新可做 @suhailopensource 于 78 天前认领，目前没有进行中的 PR。 未关闭
难度 2/5 1-3 小时 新手友好度 35/100
testing-library/react-testing-library#1466 · 1 条评论 ·
-
难度 4/5 3-5 天 新手友好度 30/100
testing-library/react-testing-library#1459 · 2 条评论 ·
-
perf: optimize container lookup with early exit可能重新可做 @Ch-Abhinav-Chowdary 于 304 天前认领，目前没有进行中的 PR。 未关闭
难度 1/5 1 小时以内 新手友好度 35/100
testing-library/react-testing-library#1430 · 1 条评论 ·
-
`fireEvent.mouseEnter` does not forward `relatedTarget` (relatedTarget is the window instead)可能已有人在做 @swarnim02 于 321 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 55/100
查看 testing-library/react-testing-library 的全部 Issue
相似的 Issue
-
check:passed feeds:add
难度 2/5 1 小时以内 新手友好度 62/100
-
bug
难度 2/5 1-3 小时 新手友好度 70/100
codex-team/editor.js#3037 ·
-
No Code Attached Yet
难度 2/5 1-3 小时 新手友好度 72/100
joomla/joomla-cms#48626 ·
维护者通常 1 天内回复
-
complexity: trivial good first issue impact: low
难度 1/5 1 小时以内 新手友好度 78/100
ueberdosis/tiptap#8522 ·
维护者通常 1 天内回复
-
internal os specific
难度 2/5 1-3 小时 新手友好度 65/100
frostney/GocciaScript#1688 ·
维护者通常 1 天内回复