我自己踩了今早刚修过的同一类坑，而且是本地数据与 CI 全新租户的差异掩盖了它：
getByText(“Applied”) 在 CI 里匹配到两个元素 —— 状态迁移按钮，以及「Upload a resume on your profile to record which one you applied with…」这句提示。这句提示只在没有简历的租户里出现；我本地的测试用户有默认简历，所以本地永远看不到它。
修法不是加 exact（按钮和徽章文本都是 “Applied”，切换瞬间会同时存在），而是断言状态机本身

加 exact是什么意思？

“加 exact” 的含义

在前端测试库（如 React Testing Library）中，getByText等查询方法有一个exact选项：

// 默认行为：exact 为 true，要求文本**完全匹配**screen.getByText("Applied")// 显式加 exact: true（和默认一样）screen.getByText("Applied",{exact:true})// exact: false，允许**子串/部分匹配**screen.getByText("Applied",{exact:false})

在你描述的场景中

有人可能建议这样修：

// 加 exact: true，期望只匹配按钮上的精确文本 "Applied"// 而不去匹配那段包含 "applied" 的长提示句screen.getByText("Applied",{exact:true})

因为提示句是“Upload a resume on your profile to record which one youappliedwith…”，它不是精确等于"Applied"，所以exact: true理论上能排除掉它。

为什么作者说"修法不是加 exact"

作者指出即使加了exact: true，问题依然存在，因为：

按钮和徽章（badge）的文本都是"Applied"

在状态切换的瞬间，按钮和状态徽章会同时存在于 DOM 中，两者的文本都精确等于"Applied"。所以exact无法区分它们，getByText("Applied")仍然会匹配到两个元素而报错。

作者选择的正确修法

不再依赖文本查询来定位元素，而是断言状态机本身——比如直接检查组件的状态逻辑、检查特定状态标识（如data-testid、ARIA 属性等），从根本上避免文本匹配带来的脆弱性。