NestJS测试中jest.fn嵌套属性缓存问题的分析与解决

问题背景

在NestJS项目中使用@golevelup/ts-jest进行单元测试时，开发者发现了一个关于模拟函数嵌套属性赋值的缓存问题。具体表现为：当开发者尝试修改模拟对象中嵌套函数的属性时，新设置的值无法覆盖原有的缓存值。

问题复现

考虑以下测试用例：

it('nested properties mocks should be able to set properties and override cache', () => {
  const mock = createMock<any>();
  const autoMockedFn = mock.nested.f;
  expect(typeof autoMockedFn).toEqual('function');
  const myFn = () => 5;
  mock.nested.f = myFn;
  expect(mock.nested.f === myFn).toBeTruthy(); // 这里会失败
});

在这个测试中，我们首先创建了一个模拟对象，然后访问其嵌套属性nested.f，这会自动创建一个模拟函数。接着我们尝试将一个自定义函数myFn赋值给这个嵌套属性，但最后断言失败，表明新值没有被正确设置。

技术分析

这个问题本质上源于Jest模拟函数的实现机制。当使用createMock创建模拟对象时，它会为对象的所有属性（包括嵌套属性）自动创建模拟函数。这些模拟函数会被缓存以提高性能。

问题出现在当我们尝试修改嵌套属性时：

1. 第一次访问mock.nested.f时，系统自动创建并缓存了一个模拟函数
2. 当我们尝试用mock.nested.f = myFn赋值时，由于缓存机制的存在，这个赋值操作没有真正生效
3. 后续访问mock.nested.f仍然返回之前缓存的模拟函数，而不是我们新设置的值

解决方案

@golevelup/ts-jest在0.5.4版本中修复了这个问题。修复的核心思路是：

1. 确保属性赋值操作能够绕过缓存机制
2. 当用户显式设置属性值时，优先使用用户设置的值而不是自动生成的模拟值
3. 保持原有自动模拟功能的同时，增加对显式赋值的支持

最佳实践

在实际测试中，如果需要修改模拟对象的嵌套属性，建议：

1. 对于简单的属性覆盖，可以直接使用赋值操作（如mock.nested.f = myFn）
2. 对于需要保留模拟功能但修改部分行为的场景，可以使用jest.spyOn或mockImplementation
3. 确保使用的@golevelup/ts-jest版本至少为0.5.4

总结

这个问题的修复使得NestJS测试中的模拟对象行为更加符合开发者预期，特别是在需要动态修改嵌套属性场景下。理解这一机制有助于开发者编写更可靠、更灵活的单元测试，同时也提醒我们在使用测试工具时要关注其内部实现细节可能带来的边界情况。