本文详解为何直接 stub 模块内 require() 的第三方函数无效，并提供可落地的模块解耦 + Sinon 精准打桩方案，彻底解决测试中“已 mock 却仍执行真实逻辑并抛出 ENOENT”问题。
本文详解为何直接 stub 模块内 `require()` 的第三方函数无效，并提供可落地的模块解耦 + sinon 精准打桩方案，彻底解决测试中“已 mock 却仍执行真实逻辑并抛出 enoent”问题。
在 Node.js 单元测试中，一个常见误区是：试图在测试文件中直接覆盖被测模块内部 require() 的第三方函数引用。正如问题所示，尽管创建了 Sinon stub 并赋值给 myCustomFunctions.thirdPartyFunc，但实际运行时仍触发了真实 third-party-lib 的文件系统调用（如 lstat('something')），最终抛出 ENOENT: no such file or directory —— 这说明 stub 根本未生效。
根本原因在于：模块作用域隔离与 require() 的缓存机制。
myFunc 内部的 const thirdPartyFunc = require('third-party-lib') 是在模块加载时立即执行的，其返回值被闭包捕获并绑定到函数作用域。你在测试中修改 myCustomFunctions.thirdPartyFunc 属性，只是向导出对象添加了一个新字段，完全不影响 myFunc 内部已解析并持有的 thirdPartyFunc 引用。因此，stub 从未被调用，真实函数照常执行。
✅ 正确解法：将第三方依赖显式抽象为可注入的模块层，实现依赖解耦与可控替换。
步骤一：创建中间适配层（推荐命名 thirdPartyAdapter.js）
// src/adapters/thirdPartyAdapter.js
const thirdPartyLib = require('third-party-lib');
module.exports = {
// 显式导出需被模拟的函数（注意：此处应为具体函数名，非模块本身）
execute: thirdPartyLib, // 假设 third-party-lib 默认导出即为目标函数
// 若需调用特定方法，例如 thirdPartyLib.process，则写为：
// process: thirdPartyLib.process
};步骤二：重构被测模块，依赖适配层而非直接 require
// src/myCustomFunctions.js
const thirdPartyAdapter = require('./adapters/thirdPartyAdapter'); // ← 关键变更
function myFunc(resource) {
try {
// 使用适配层提供的函数，而非直接 require
let thirdPartyFuncOutput = thirdPartyAdapter.execute(resource.path); // 注意传参逻辑
return thirdPartyFuncOutput;
} catch (e) {
vscode.window.showErrorMessage(`Something went wrong: ${e}`);
throw e; // 建议显式 re-throw 便于测试断言
}
}
module.exports = { myFunc };步骤三：在测试中精准 stub 适配层导出项
// test/myCustomFunctions.test.js
const sinon = require('sinon');
const chai = require('chai');
const expect = chai.expect;
const myCustomFunctions = require('../../src/myCustomFunctions.js');
const thirdPartyAdapter = require('../../src/adapters/thirdPartyAdapter.js');
suite('testing myCustomFunctions.js', function () {
let sandbox;
setup(function () {
sandbox = sinon.createSandbox();
// Stub 适配层的导出函数（非被测模块自身属性！）
sandbox.stub(thirdPartyAdapter, 'execute').returns('Hi Mom');
});
teardown(function () {
sandbox.restore();
});
test('Should generate expected output for valid resource', async function () {
const mockedInput = { path: 'something' };
const result = await myCustomFunctions.myFunc(mockedInput);
// 验证结果与调用行为
expect(result).to.equal('Hi Mom');
expect(thirdPartyAdapter.execute.calledOnce).to.be.true;
expect(thirdPartyAdapter.execute.firstCall.args[0]).to.equal('something');
});
});⚠️ 关键注意事项
- 不要 stub require() 返回值本身：Node.js 的 require 缓存和模块封装机制使此类操作不可靠且违反模块化原则。
- Stub 对象必须与被测代码实际访问路径一致：thirdPartyAdapter.execute 是运行时真实调用链路，Sinon 才能拦截。
- 确保测试环境加载顺序正确：先 require 适配层再 require 被测模块，否则 stub 可能晚于模块初始化。
- 若第三方库为 ESM（ES6 Module）：需使用 import { stub } from 'sinon' 及动态 import()，或借助 @sinonjs/fake-timers 等兼容方案（Sinon v15+ 已支持 ESM stub）。
- 生产环境零侵入：适配层仅用于解耦，不改变业务逻辑，符合 SOLID 中的依赖倒置原则。
通过这一结构化改造，你不仅解决了当前的 ENOENT 问题，更构建了可维护、可扩展的测试友好架构——所有外部依赖均通过明确定义的接口注入，mock 成为简单、稳定、可验证的操作。
