Node.js 18（CommonJS）中如何Stub直接导出函数的模块？

一、Stub被测文件下一级依赖的实现方案 #

因为FileConverter未导出且无法修改源码，核心思路是拦截file-converter.js对其依赖模块file-converter-codec.js的导入，用自定义Stub函数替换原getCodec。在CommonJS环境下，proxyquire是最适配的工具——它能直接替换目标模块的局部依赖，完全不影响全局模块缓存。

具体步骤： #

1. 安装proxyquire（未安装的话）

npm install proxyquire --save-dev

2. 在测试文件index.js中，用proxyquire加载file-converter.js并替换其依赖：

const proxyquire = require('proxyquire');
const sinon = require('sinon'); // 用Sinon生成Stub，也可以手写简单函数

// 生成Stub版getCodec，返回预设的测试数据
const stubGetCodec = sinon.stub().resolves({ /* 你的测试用Codec数据 */ });

// 用proxyquire替换file-converter.js的依赖：将'./file-converter-codec'替换为包含Stub的对象
const fileConverterModule = proxyquire('./file-converter', {
  // 注意匹配原模块的导出方式：
  // 如果file-converter-codec是默认导出（module.exports = async () => {...}）：
  './file-converter-codec': { default: stubGetCodec },
  // 如果是命名导出（module.exports.getCodec = async () => {...}）：
  // './file-converter-codec': { getCodec: stubGetCodec }
});

// 现在测试原逻辑即可，FileConverter内部调用的getCodec会自动使用Stub版本，不会触发真实API请求

关键说明：无论FileConverter是否导出，只要file-converter.js内部导入了file-converter-codec，proxyquire就能在加载模块时完成依赖替换，完全不需要接触私有类本身。

二、关于“提前Stub axios再加载file-converter-codec.js”的思路确认 #

这个思路技术上可行，但存在明显缺陷，不推荐使用：

• 全局污染风险：CommonJS模块是加载时缓存的，提前Stub axios会污染全局模块缓存，导致其他测试用例的axios调用被意外拦截，引发不可预期的问题。
• 偏离需求初衷：你希望Stub被测文件的下一级依赖，但该方案仍直接操作了深层的axios，不符合“Stub更上层依赖”的设计原则。
• 维护性差：如果后续file-converter-codec.js更换HTTP库（比如从axios换成fetch），该Stub逻辑会直接失效；而用proxyquire替换getCodec的方案，只要函数签名不变，无需修改测试代码。

内容的提问来源于stack exchange，提问作者erakis