NestJS测试工具中Symbol.toPrimitive引发的对象污染问题分析

问题背景

在使用NestJS的测试工具包@golevelup/ts-jest时，开发者在0.6.0版本中引入了一个新特性：为所有模拟对象添加了Symbol.toPrimitive方法。这个改动原本是为了更好地处理对象到原始值的隐式转换，但却意外导致了测试数据污染的问题。

问题现象

在0.5.x版本中，开发者可以这样创建请求模拟对象：

const requestMock = createMock<Request>({
  body: {
    user_email: '[e-mail]'
  }
});

测试代码能够正确获取到预期的请求体数据。但在升级到0.6.0后，同样的代码却会在请求体对象中额外获得一个[Symbol(Symbol.toPrimitive)]属性，导致测试断言失败。

技术分析

问题的根源在于0.6.0版本中新增的一段代码，它会为所有模拟对象和函数添加Symbol.toPrimitive方法：

if (typeof mockedProp === 'object' || typeof mockedProp === 'function') {
  mockedProp[Symbol.toPrimitive] = (hint) => {
    if (hint === 'string') {
      return 'mocked';
    }
    if (hint === 'number') {
      return 0;
    }
    throw new TypeError();
  };
}

这段代码的设计初衷是好的，它确保了模拟对象在被隐式转换为原始值时的行为一致性。然而，它没有考虑到开发者可能直接比较模拟对象内容的场景，导致测试数据被意外修改。

解决方案

针对这个问题，社区提出了修复方案，主要思路是：

1. 限制Symbol.toPrimitive的添加范围，避免污染用户数据
2. 确保只在顶层模拟对象上添加这个方法，而不是递归地为所有嵌套对象都添加

这种修改既保留了原始功能，又避免了数据污染问题。

经验总结

这个问题给我们的启示是：

1. 在修改测试工具的核心行为时，需要考虑各种使用场景
2. 对模拟对象的修改应当谨慎，避免影响测试数据的纯净性
3. 新特性的引入应当有完善的测试覆盖，包括边缘用例

对于NestJS开发者来说，遇到类似问题时可以：

• 检查测试工具的版本变更日志
• 考虑是否需要锁定特定版本
• 在测试断言中使用更精确的匹配方式（如toStrictEqual）

这个问题也提醒我们，在测试工具的设计中，保持API的稳定性和可预测性至关重要。