为何Testing Library文档使用toBeInTheDocument？是否存在冗余？

两种写法的核心差异 #

• 直接执行 screen.getByText(/you are home/i)：
  找不到匹配元素时会直接抛出查询失败的错误，但如果找到元素，这行代码只是完成了一次元素查询，不会被测试框架（如Jest）当作一个通过的断言，测试报告里不会记录这个操作的成功状态。
• 用断言包裹的写法 expect(screen.getByText(/you are home/i)).toBeInTheDocument()：
  这是一个完整的测试断言。找不到元素时同样会抛错；找到元素时，会明确标记这个断言通过，测试报告会清晰记录这个验证结果。

为什么文档要使用toBeInTheDocument()？这不是冗余操作 #

1. 测试意图更明确
   直接调用查询的写法，其他人看代码时可能会疑惑：这行是为了拿元素做后续操作？还是单纯验证元素存在？用断言包裹后，能清晰传达“我要验证这个文本对应的元素存在于DOM中”的测试目的。

2. 测试报告更完整
   测试框架会统计断言的数量和结果。直接查询的写法不会被计数，而带expect的写法会被记录为一个成功的断言，让测试报告的统计信息更准确，也能让你清楚知道自己到底验证了哪些点。

3. 统一测试风格
   Testing Library的设计理念就是让测试代码贴近用户行为，清晰表达预期。用断言包裹查询结果，能保持所有测试用例的风格一致，符合“用断言明确表达预期结果”的最佳实践。

4. 避免潜在的代码修改风险
   如果后续有人修改代码，把查询结果赋值给变量（比如const elem = screen.getByText(...)），但忘记添加断言，测试可能会因为查询成功而通过，但实际上没有明确验证元素存在的意图。用expect包裹能从根源上避免这种情况。

内容的提问来源于stack exchange，提问作者Braven