Enzyme组件测试：toBeTruthy断言是否存在假阳性及相关报错

问题原因分析与解决方案 #

1. toBeTruthy断言的假阳性问题 #

你之前的断言确实是完全无效的假阳性：

• Enzyme的find()方法无论是否匹配到目标元素，都会返回一个ShallowWrapper实例，这个实例是普通JS对象，永远为truthy值。哪怕匹配数为0，返回的Wrapper也会让toBeTruthy()断言直接通过，根本没有实际校验目标元素是否真的渲染存在。
• 额外注意：你当前用shallow渲染的根组件是Redux的Provider，浅渲染只会渲染根组件的一层，不会递归进入子组件TodoItem的内部渲染逻辑。也就是说哪怕后续你修正了断言语法，也无法通过这种渲染方式找到.marked这类TodoItem内部的DOM节点。

2. .to.have.lengthOf报错的原因 #

这个报错是断言库语法混用导致的：

• 你写的.to.have.lengthOf是Chai断言库的BDD风格语法，但当前测试环境用的是Jest内置的expect对象，它的链式API中没有have这个属性。执行到expect(...).to.have时，to返回的Jest断言对象上不存在have字段，值为undefined，后续访问其属性就会抛出你看到的报错。
• 对应解决方案分两种：
  • 若使用Jest原生断言：直接替换为Jest支持的语法，长度校验用.toHaveLength(1)即可，例如expect(component.find(TodoItem)).toHaveLength(1)
  • 若想继续使用Chai风格语法：需要额外安装chai、enzyme-chai适配包，导入Chai的expect替换Jest自带的expect即可。

测试写法优化建议 #

要正确校验TodoItem的内部渲染逻辑（比如.marked类是否存在），建议调整渲染方式：

• 不要用shallow包裹Provider再找内部组件：你可以先mock项目里的useAppDispatch hook，直接渲染TodoItem本身，无需依赖Provider：

// 先mock redux hook
const mockDispatch = jest.fn();
jest.mock('你项目的useAppDispatch引入路径', () => ({
  useAppDispatch: () => mockDispatch
}));

it('should have class marked if done is true', () => {
  // 直接渲染TodoItem，不需要Provider包裹
  const component = shallow(<TodoItem item={{ ...item, done: true }} />);
  // 使用Jest原生断言校验类名
  expect(component.find('td.marked')).toHaveLength(1);
});

• 如果必须测试Provider的集成逻辑，改用mount而非shallow，才能完整渲染组件树的所有内部DOM节点。

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