发现于 #3459(PR #3464)的实现过程 —— 我给自己新增的两个看板测试补了这条预载,顺手发现同包里既有的一个文件没有。属于潜在 flaky,当前没见它红过,故打 finding、不进队列。
事实
packages/plugin-kanban/src/index.tsx:
const LazyKanban = React.lazy(() => import('./KanbanImpl'));
...
<Suspense fallback={<Skeleton className="w-full h-[600px]" />}>
<LazyKanban ... />
</Suspense>packages/plugin-kanban/src/KanbanRenderer.uncolumned.test.tsx 直接渲染 KanbanRenderer,两条断言都在这个 Suspense 边界之后:
expect(await screen.findByText('Orphaned card')).toBeInTheDocument(); // 第 42 行
expect(await screen.findByText('Matches')).toBeInTheDocument(); // 第 60 行文件顶部只 import { KanbanRenderer } from './index' —— 那只登记了 lazy 工厂,并不执行 import('./KanbanImpl')。所以首次渲染时的动态 import 被记在 RTL findBy 默认的 1000ms 预算里。
AGENTS.md §测试纪律 正是这一条:满并行下实测一次首包 import() 可达 976ms,已吃掉 1000ms 预算的 97.6%,红绿取决于机器负载而非被测代码。
该文件在 vitest.config.mts 的 heavyDomTests 里,但这不解决问题:vitest.setup.dom.tsx 只 side-effect import 了 @object-ui/components / fields / plugin-dashboard / plugin-grid,没有 plugin-kanban;而且即使有,./index 也只登记工厂,不会预热 KanbanImpl。
修法
按 §测试纪律,在测试文件模块作用域直接 import,并加一行注释说明原因:
specifier 必须与 ./index 里的完全一致(ESM 按解析后的 specifier 缓存),这样组件自己的 lazy 工厂才会立刻 resolve。不要用 beforeAll 预热 —— 它受 hookTimeout(10s)约束,比它取代的 testTimeout(15s)更窄,而且已被 object-ui/no-dynamic-import-in-test-hook 机械禁止。
PR #3464 里给 ObjectKanban.overlayTitleI18n.test.tsx 与 ObjectKanban.overlayTitleNoProviderFallback.test.tsx 做的就是这个,可直接照抄注释。
同包其余两个文件不受影响(已核)
registration.test.tsx —— 断言的是注册表解析,不落在 lazy 边界之后;cardPredicateScope.test.tsx —— 已经静态 import KanbanBoard from './KanbanImpl' 并直接渲染,天然规避。
定级说明
按 §测试纪律 的判据这是「潜在竞态」而不是「已发生的失败」:目前没有记录显示该文件红过。但这类问题的症状是负载相关的偶发红,单跑永远绿,所以不宜等它真红了再修。相关前情:objectui#3010。
发现于 #3459(PR #3464)的实现过程 —— 我给自己新增的两个看板测试补了这条预载,顺手发现同包里既有的一个文件没有。属于潜在 flaky,当前没见它红过,故打
finding、不进队列。事实
packages/plugin-kanban/src/index.tsx:packages/plugin-kanban/src/KanbanRenderer.uncolumned.test.tsx直接渲染KanbanRenderer,两条断言都在这个 Suspense 边界之后:文件顶部只
import { KanbanRenderer } from './index'—— 那只登记了 lazy 工厂,并不执行import('./KanbanImpl')。所以首次渲染时的动态 import 被记在 RTLfindBy默认的 1000ms 预算里。AGENTS.md §测试纪律 正是这一条:满并行下实测一次首包
import()可达 976ms,已吃掉 1000ms 预算的 97.6%,红绿取决于机器负载而非被测代码。该文件在
vitest.config.mts的heavyDomTests里,但这不解决问题:vitest.setup.dom.tsx只 side-effect import 了@object-ui/components/fields/plugin-dashboard/plugin-grid,没有 plugin-kanban;而且即使有,./index也只登记工厂,不会预热KanbanImpl。修法
按 §测试纪律,在测试文件模块作用域直接 import,并加一行注释说明原因:
specifier 必须与
./index里的完全一致(ESM 按解析后的 specifier 缓存),这样组件自己的 lazy 工厂才会立刻 resolve。不要用beforeAll预热 —— 它受hookTimeout(10s)约束,比它取代的testTimeout(15s)更窄,而且已被object-ui/no-dynamic-import-in-test-hook机械禁止。PR #3464 里给
ObjectKanban.overlayTitleI18n.test.tsx与ObjectKanban.overlayTitleNoProviderFallback.test.tsx做的就是这个,可直接照抄注释。同包其余两个文件不受影响(已核)
registration.test.tsx—— 断言的是注册表解析,不落在 lazy 边界之后;cardPredicateScope.test.tsx—— 已经静态import KanbanBoard from './KanbanImpl'并直接渲染,天然规避。定级说明
按 §测试纪律 的判据这是「潜在竞态」而不是「已发生的失败」:目前没有记录显示该文件红过。但这类问题的症状是负载相关的偶发红,单跑永远绿,所以不宜等它真红了再修。相关前情:objectui#3010。