Node.js单元测试mock依赖失败：无法读取config.json求助

看起来你踩了个proxyquire使用的常见误区：当前的stubs目标完全错了，没拦截到真正触发报错的read-config模块调用。

问题根源 #

报错来自library.js里的readConfig('./config.json')——测试运行时这个调用还在执行真实的文件读取操作，要么是测试环境下相对路径和业务代码的路径逻辑不匹配（比如测试文件在test目录，./config.json的实际位置不对），要么你本来就不想依赖真实配置文件。但你现在的stubs只尝试mock了./library这类本地模块，完全没处理read-config这个第三方依赖，所以它还是会真实执行并找不到文件。

正确解决方案 #

你需要用proxyquire直接mockread-config模块，让它返回你预设的配置对象，跳过真实文件读取步骤。具体代码示例：

const proxyquire = require('proxyquire');
const sinon = require('sinon');

// 定义你需要的模拟配置内容
const mockConfig = {
  // 这里填入业务代码需要的配置项，比如：
  apiEndpoint: 'https://test.example.com',
  maxRetries: 3
};

// 用proxyquire加载index.js，同时替换read-config模块
const index = proxyquire('./index.js', {
  // 第三方模块直接以模块名为key
  'read-config': sinon.stub().returns(mockConfig)
});

// 接下来执行你的测试断言逻辑

为什么之前的方法不生效？ #

1. 你尝试mock./library的写法存在问题：proxyquire mock本地模块时，必须保证路径和被测试文件（index.js）里require的路径完全一致。而且就算mock成功，你也只是替换了整个library模块，而非里面的read-config调用。
2. 你尝试修改的业务代码用了异步的fs.readFile，但原read-config是同步加载配置的——这不仅改动了业务逻辑，也违背了单元测试不修改业务代码的原则。

额外提醒 #

如果你的index.js也直接require了read-config，上面的mock同样会生效：proxyquire会替换所有被加载模块里对read-config的引用，不管是index.js还是它依赖的library.js里的调用。

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