理解Jest模块模拟的挑战
在使用jest进行单元测试时，我们经常需要模拟（mock）某些函数或模块的行为，以隔离测试目标并控制其依赖。然而，当被模拟的函数在另一个导入的模块中被调用时，有时会遇到模拟不生效的问题。
问题现象：
考虑一个常见的场景：我们有一个sendDataHandler函数，它内部调用了另一个函数sendToEH。我们希望测试sendDataHandler是否正确地调用了sendToEH。直观的测试方法可能是直接在测试文件中模拟app.sendToEH：
// 假设 app 是一个包含 sendDataHandler 和 sendToEH 的对象 app.sendToEH = jest.fn(); // 模拟 sendToEH await app.sendDataHandler(req, res, next); // 调用 sendDataHandler expect(app.sendToEH).toHaveBeenCalled(); // 期望模拟函数被调用
然而，在许多情况下，这样的测试会失败。调试时会发现，sendDataHandler在执行时，并没有调用我们设置的jest.fn()模拟函数，而是调用了原始的sendToEH实现。这表明，在sendDataHandler内部，它访问的sendToEH与我们在测试文件中模拟的app.sendToEH并非同一个引用。
如果我们在调用sendDataHandler之前，先直接调用一次模拟函数，测试反而会通过：
app.sendToEH = jest.fn();
await app.sendToEH('asdf'); // 先调用一次模拟函数
await app.sendDataHandler(req, res, next);
expect(app.sendToEH).toHaveBeenCalled(); // 此时测试通过这进一步证实了问题在于sendDataHandler内部的调用没有指向我们设置的模拟。
根本原因分析：
这种现象的根本原因在于JavaScript模块的导入和函数引用的工作方式。当一个模块（例如包含sendDataHandler的模块）导入并使用sendToEH时，它可能获得的是sendToEH的原始引用。即使在测试文件中，我们对一个全局对象或导入对象上的属性进行了模拟（例如app.sendToEH = jest.fn()），如果sendDataHandler内部访问sendToEH的方式不是通过这个可变的app对象属性，而是通过一个直接的、在模块加载时就确定的引用，那么我们的模拟就不会生效。模块系统通常会缓存导入的模块，这意味着即使我们修改了外部的引用，模块内部可能仍然持有旧的引用。
解决方案：通过统一导出对象管理函数引用
为了解决这个问题，核心思想是确保在模块内部和测试文件中，对目标函数的访问都通过同一个可变的引用路径。一种有效的方法是将所有相关函数封装在一个对象中，并导出这个对象。这样，当测试文件导入并修改这个对象中的函数引用时，模块内部通过相同对象访问的函数也会指向被修改后的模拟函数。
模块代码实现：
我们将sendToEH和sendDataHandler都定义在一个对象exportFunctions内部，并导出这个对象。关键在于sendDataHandler内部调用sendToEH时，也通过exportFunctions.sendToEH来访问。
// module.js
var sendToEH = function sendToEH() {
console.log('Original sendToEH called');
};
var sendDataHandler = function sendDataHandler() {
console.log('sendDataHandler calling sendToEH');
exportFunctions.sendToEH(); // 通过 exportFunctions 对象调用
};
const exportFunctions = {
sendToEH,
sendDataHandler
};
export default exportFunctions; // 导出整个对象测试代码实现：
在测试文件中，我们导入exportFunctions对象，然后直接模拟该对象上的sendToEH属性。
// test.js
import app from './module'; // 导入 exportFunctions 对象，这里假设命名为 app
describe('sendDataHandler', () => {
beforeEach(() => {
// 在每次测试前重置模拟
app.sendToEH = jest.fn();
});
test('should call sendToEH when sendDataHandler is invoked', async () => {
const req = {}; // 模拟请求对象
const res = {}; // 模拟响应对象
const next = jest.fn(); // 模拟 next 函数
await app.sendDataHandler(req, res, next); // 调用 sendDataHandler
expect(app.sendToEH).toHaveBeenCalledTimes(1); // 期望模拟函数被调用一次
});
});原理阐释：
通过这种方式，app变量在测试文件中引用的是module.js中导出的exportFunctions对象。当我们在测试中执行app.sendToEH = jest.fn()时，我们实际上是修改了exportFunctions对象上的sendToEH属性，将其指向了一个Jest模拟函数。
由于sendDataHandler内部也是通过exportFunctions.sendToEH()来调用sendToEH的，它会访问到这个已经被修改为模拟函数的引用。因此，当sendDataHandler被调用时，它将正确地触发我们设置的jest.fn()，从而使测试通过。这种方法确保了模块内部和测试外部对目标函数的访问路径和引用始终保持一致。
最佳实践与注意事项
- 统一引用是关键： 在模块化应用中进行测试时，确保被模拟函数在所有相关代码路径中都通过同一个可变引用被访问，是成功模拟的关键。
- 封装相关函数： 将一组逻辑相关的函数封装到一个对象中并导出，不仅有助于解决模拟问题，还能提高代码的组织性和可维护性。
- 避免直接导出函数： 尽量避免直接导出单个函数，如果这个函数可能需要在内部被其他导出的函数调用并被模拟。如果必须直接导出，可以考虑使用jest.mock()来模拟整个模块，但这通常比模拟对象属性更复杂。
- 明确模拟范围： 理解Jest的jest.mock()、jest.spyOn()以及直接赋值jest.fn()之间的区别和适用场景。本教程主要关注了直接赋值jest.fn()在特定引用场景下的问题和解决方案。
总结
当Jest模拟函数在跨模块调用中不生效时，通常是由于模块内部和测试外部对函数的引用不一致造成的。通过将相关函数封装在一个统一的导出对象中，并确保模块内部也通过该对象来访问这些函数，可以有效地解决这一问题。这种模式确保了模拟的函数引用能够贯穿到所有调用路径中，从而实现可靠的单元测试。
