问题剖析：Jest Mock 的引用挑战
在进行单元测试时，我们经常需要模拟（mock）某些函数的行为，以隔离测试目标，确保测试的独立性。然而，当被测试的模块中存在函数 a 调用函数 b 的场景，并且函数 b 是模块内部或通过模块导出的一个属性时，直接在测试文件中对全局对象或导入对象上的函数 b 进行 mock，可能会遇到一个常见的陷阱：mock 的实例与模块内部实际调用的实例不一致。
例如，假设我们有一个 sendDataHandler 函数，它内部会调用 sendToEH 函数：
// app.js (或类似模块)
var sendToEH = function sendToEH() { /* ... */ };
var sendDataHandler = function sendDataHandler() {
sendToEH(); // 内部调用 sendToEH
};
// 假设这是通过某种方式暴露的，例如作为 app 对象的方法
// app.sendToEH = sendToEH;
// app.sendDataHandler = sendDataHandler;在测试文件中，如果尝试如下 Mock：
// test.js app.sendToEH = jest.fn(); // Mock app 对象上的 sendToEH await app.sendDataHandler(req, res, next); expect(app.sendToEH).toHaveBeenCalled(); // 期望失败
这种测试往往会失败。原因在于，app.sendToEH = jest.fn() 确实成功地 Mock 了 app 对象上的 sendToEH 方法。但是，当 app.sendDataHandler 被调用时，它内部执行的 sendToEH() 调用的，是模块内部原始的 sendToEH 函数实例，而不是我们在测试文件中对 app.sendToEH 设置的 Mock 实例。这两个 sendToEH 引用是不同的，导致 Mock 无法被识别。
如果测试代码改为：
app.sendToEH = jest.fn();
await app.sendToEH('asdf'); // 直接调用 Mock 后的 sendToEH
await app.sendDataHandler(req, res, next);
expect(app.sendToEH).toHaveBeenCalled(); // 此时测试通过这个例子进一步证明了问题所在：直接调用 app.sendToEH 会触发 Mock，但通过 sendDataHandler 间接调用则不会，因为 sendDataHandler 仍然引用着原始的函数。
解决方案：导出函数集合对象
要解决这个问题，关键在于确保模块内部调用的函数与测试文件中 Mock 的函数是同一个引用。一种有效的策略是将所有相关函数封装在一个对象中，并导出这个对象。这样，模块内部的函数调用和测试文件中的 Mock 操作都将作用于这个对象的同一个属性引用上。
模块实现示例
修改模块的结构，将 sendToEH 和 sendDataHandler 都作为 exportFunctions 对象的方法：
// 假设这是你的业务逻辑模块文件 (e.g., myModule.js)
// 定义内部函数
var sendToEH = function sendToEH() {
console.log("Original sendToEH called.");
// 实际的数据发送逻辑
};
// 定义处理函数，它将通过 exportFunctions 对象调用 sendToEH
var sendDataHandler = function sendDataHandler() {
console.log("sendDataHandler called, invoking sendToEH via exportFunctions.");
exportFunctions.sendToEH(); // 通过对象引用调用 sendToEH
};
// 将所有相关函数封装在一个对象中并导出
const exportFunctions = {
sendToEH,
sendDataHandler
};
export default exportFunctions; // 导出这个对象在这个修改后的模块中，sendDataHandler 不再直接调用一个全局或内部的 sendToEH，而是通过 exportFunctions.sendToEH() 来调用。这意味着 sendDataHandler 依赖于 exportFunctions 对象上的 sendToEH 引用。
测试用例编写
现在，在测试文件中，我们可以导入这个 exportFunctions 对象，并直接 Mock 它上面的 sendToEH 方法。
// 假设你的测试文件 (e.g., myModule.test.js)
import app from './myModule'; // 导入导出的对象，这里假设导入后命名为 app
describe('sendDataHandler', () => {
beforeEach(() => {
// 在每次测试前重置 Mock
// 注意：这里我们直接 Mock app.sendToEH，因为 app 就是 exportFunctions 对象
app.sendToEH = jest.fn();
});
test('should call sendToEH when sendDataHandler is invoked', async () => {
const req = {}; // 模拟请求对象
const res = {}; // 模拟响应对象
const next = jest.fn(); // 模拟 next 函数
// 调用 sendDataHandler
await app.sendDataHandler(req, res, next);
// 验证 app.sendToEH 是否被调用
expect(app.sendToEH).toHaveBeenCalledTimes(1);
// 还可以验证调用参数等
// expect(app.sendToEH).toHaveBeenCalledWith(/* 期望的参数 */);
});
test('sendToEH should not be called if sendDataHandler is not invoked', async () => {
expect(app.sendToEH).not.toHaveBeenCalled();
});
});通过这种方式，我们导入的 app 对象（即 exportFunctions 对象）与模块内部 sendDataHandler 所引用的 exportFunctions 对象是同一个实例。因此，当我们在测试文件中执行 app.sendToEH = jest.fn() 时，我们实际上是修改了 exportFunctions 对象上 sendToEH 的引用，使其指向我们的 Mock 函数。当 sendDataHandler 内部调用 exportFunctions.sendToEH() 时，它就会调用到这个 Mock 后的函数，从而使 expect(app.sendToEH).toHaveBeenCalled() 能够正确地捕获到调用。
总结与最佳实践
这种模式的关键在于 一致的引用。当模块内部的函数依赖于通过某个对象暴露的其他函数时，确保测试时 Mock 的是这个对象的相同属性。
核心要点：
- 封装函数： 将模块中相互关联或需要被 Mock 的函数封装在一个对象中。
- 通过对象引用调用： 模块内部的函数在调用其他相关函数时，应通过这个封装对象的属性来调用，而不是直接调用原始函数。
- 直接 Mock 导出对象： 在测试文件中，直接对导入的这个对象上的方法进行 Mock。
这种方法不仅解决了 Jest Mock 的引用问题，也促进了模块内部函数之间更清晰的依赖关系，有助于编写更健壮、更易于维护和测试的代码。在设计模块时，考虑到测试的需求，采用这种导出函数集合的模式，可以显著提升单元测试的效率和准确性。
