在 Jest 测试中，当一个函数通过导入的模块间接调用另一个函数时，直接对外部对象进行 Mock 可能无法生效，因为被调用的函数实例并非 Mock 后的实例。本文将介绍一种有效的解决方案，通过将相关函数封装并导出为一个对象，确保测试时 Mock 的是与模块内部调用相同的函数引用，从而实现准确的单元测试。
问题剖析：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.jsapp.sendToEH = jest.fn(); // Mock app 对象上的 sendToEHawait 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 后的 sendToEHawait 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 对象调用 sendToEHvar 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'; // 导入导出的对象，这里假设导入后命名为 appdescribe('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 的引用问题，也促进了模块内部函数之间更清晰的依赖关系，有助于编写更健壮、更易于维护和测试的代码。在设计模块时，考虑到测试的需求，采用这种导出函数集合的模式，可以显著提升单元测试的效率和准确性。
以上就是Jest 测试中处理模块内部函数间接调用的 Mock 策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1518191.html
微信扫一扫 
支付宝扫一扫 
