New Rule Proposal: no-unsettled-absence-query
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- eslint, javascript, typescript
- 领域
- testing-qa, tooling
调研方向
未指定任何仓库文件、测试或入口点。首先检查现有的 Testing Library ESLint 规则及其测试,然后比较所提议的失败示例和通过示例。完成的标准是:新警告能够一致地检测出尚未稳定的缺失断言,同时允许文档中说明的稳定表达式。
由索引模型根据 Issue 内容生成。
描述
Name for new rule
no-unsettled-absence-query
Description of the new rule
Asserting absence with queryBy* + .not.toBeInTheDocument() immediately after render(), before the component has settled, can produce a false positive. The element isn't there yet, not because it won't be there. The community calls this Testing Ghosts.
Testing Library's render() does flush the initial synchronous render (it's wrapped in act() internally), so for a plain component with no async behavior, checking absence right after render() is technically correct. The problem shows up when the component has async side effects like data fetching, lazy loading, state updates from useEffect, etc. In those cases the UI hasn't finished updating, and the absence check passes vacuously. Since the rule can't know whether a component has async behavior, it flags all unsettled absence assertions and lets the developer confirm intent by adding a settling expression.
This rule would enforce that an absence assertion (expect(screen.queryBy*(...)).not.toBeInTheDocument() / .not.toBeVisible()) must be preceded by a "settling" expression within the test body.
Why existing rules don't cover this:
| Existing Rule | Why it doesn't solve this |
|---|---|
prefer-presence-queries |
Enforces correct query type, but doesn't track timing relative to render |
no-await-sync-queries |
Only flags await directly on sync queries, not timing of assertions |
await-async-queries / await-async-utils |
About promise handling, not assertion ordering |
prefer-find-by |
Simplifies waitFor + getBy -> findBy, doesn't detect premature absence checks |
Related issues: #269, #411, #518 - all adjacent but none address this specific pattern.
Testing Library feature
This rule relates to the absence/presence assertion pattern described in the Appearance and Disappearance guide. Specifically, it enforces correct ordering of queryBy* absence assertions relative to async settling utilities (findBy*, waitFor, act) and sync settling queries (getBy*).
Testing Library framework(s)
All frameworks: React, Angular, Vue, Svelte, etc. The pattern applies anywhere screen.queryBy* + .not.toBeInTheDocument() is used.
What category of rule is this?
Warns about a potential error. Less valuable as an error given the call-out above of vanilla components.
Code examples
Fail:
// Absence assertion before component has settled, "Testing a Ghost"
test('shows no error', () => {
render(<AsyncComponent />);
expect(screen.queryByText('error')).not.toBeInTheDocument();
});
// Absence assertion BEFORE the awai, order matters
test('shows no error', async () => {
render(<AsyncComponent />);
expect(screen.queryByText('error')).not.toBeInTheDocument();
await screen.findByText('loaded');
});
// queryAllBy variant
test('shows no alerts', () => {
render(<AsyncComponent />);
expect(screen.queryAllByRole('alert')).not.toBeInTheDocument();
});
// Absence assertion inside waitFor - passes on first retry, still a ghost
test('shows no error', async () => {
render(<AsyncComponent />);
await waitFor(() => {
expect(screen.queryByText('error')).not.toBeInTheDocument();
});
});
Pass:
// findBy* settles the component first
test('shows no error', async () => {
render(<AsyncComponent />);
await screen.findByText('loaded');
expect(screen.queryByText('error')).not.toBeInTheDocument();
});
// waitFor settles the component first
test('shows no error', async () => {
render(<AsyncComponent />);
await waitFor(() => expect(something).toBe(true));
expect(screen.queryByRole('alert')).not.toBeInTheDocument();
});
// act settles the component first
test('shows no error', async () => {
await act(() => render(<AsyncComponent />));
expect(screen.queryByText('error')).not.toBeInTheDocument();
});
// getBy* proves sync render completed
test('shows no error', () => {
render(<Component />);
screen.getByText('visible heading');
expect(screen.queryByText('error')).not.toBeInTheDocument();
});
What counts as "settled":
- Any
awaitexpression on a preceding statement — coversfindBy*,waitFor,act, custom async helpers - A
screen.getBy*/screen.getAllBy*call — proves the sync render produced expected output
Matchers checked: .not.toBeInTheDocument(), .not.toBeVisible()
Anything else?
References:
- Testing Library: Appearance and Disappearance guide
- Kent C. Dodds: Common mistakes with React Testing Library
- Gerardo Perrucci: Stop Testing Ghosts
- react-testing-library #865 (vague similarity; in the same realm with component mounting/unmounting states)
Do you want to submit a pull request to make the new rule?
I have a working implementation with full test coverage that I'm happy to submit as a PR if this proposal is accepted.
- 主要语言
- TypeScript
- 星标
- 1.1k
- 派生
- 167
- 平均合并
- 19 小时 58 分钟
- 30 天内合并 PR
- 2
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
testing-library/eslint-plugin-testing-library 的其他 Issue
-
bug triage
难度 3/5 半天 新手友好度 58/100
-
`no-wait-for-side-effects`: side effects not detected via `userEvent.setup()` instances and when wrapped in `void`可能已有人在做 @AmineBenzaazaa 于 7 天前认领。 未关闭bug triage
难度 3/5 1-2 天 新手友好度 76/100
testing-library/eslint-plugin-testing-library#1370 · 1 条评论 ·
-
Rules don’t recognize @testing-library/angular/zoneless imports可能已有人在做 @ThiloAschebrock 于 89 天前认领。 未关闭bug
难度 3/5 1-2 天 新手友好度 70/100
-
prefer-presence-queries autofix leaves queryBy* in destructure while rewriting call site to getBy*, producing a ReferenceError可能已有人在做 @j1ang3 于 95 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 72/100
-
pinned
难度 5/5 一周以上 新手友好度 10/100
查看 testing-library/eslint-plugin-testing-library 的全部 Issue
相似的 Issue
-
[Bug]: REST API URL starting with "http" but no scheme (e.g. httpbin.org/get) is not given an http:// prefix可能已有人在做 @ItsDeadlyProgrammer 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
appsmithorg/appsmith#42471 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
ehmpathy/rhachet-roles-bhrain#705 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
Status: Triage
难度 2/5 1-3 小时 新手友好度 76/100
mermaid-js/mermaid#8546 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
braintrustdata/braintrust-sdk-javascript#2659 ·
维护者通常 1 天内回复