本文详解如何使用 sinon + chai 对 node.js 模块中「导入并调用的子模块函数」进行精准单元测试，涵盖导出方式重构、stub 替换、调用验证等关键步骤，并提供可运行示例与常见错误规避指南。
本文详解如何使用 sinon + chai 对 node.js 模块中「导入并调用的子模块函数」进行精准单元测试，涵盖导出方式重构、stub 替换、调用验证等关键步骤，并提供可运行示例与常见错误规避指南。
在 Node.js 单元测试中，验证一个模块是否真正调用了其依赖的外部函数（而非仅检查逻辑结果），是保障模块协作行为正确性的核心实践。但直接对 require() 导入的函数打桩（spy/stub）极易失败——因为该函数在被测模块内部是闭包引用，而非挂载在模块对象上的可覆盖属性。原问题中 chai.spy.on(mainModule, 'functionModule') 失败的根本原因，正是 functionModule 并非 mainModule 的自有方法，而是其私有依赖。
要可靠实现“调用验证”，必须将依赖显式暴露为可替换接口。以下是经过验证的专业实践流程：
✅ 步骤一：重构被依赖模块的导出方式
将 functionModule.js 从默认导出函数改为命名导出对象，便于 Sinon 精准 Stub：
// functionModule.js
const send = (param) => {
return param ?? undefined; // 简化逻辑，语义更清晰
};
module.exports = { send }; // 命名导出，支持 sinon.stub(module, 'send')✅ 步骤二：同步更新主模块的调用方式
在 mainModule.js 中，通过属性访问调用依赖函数，确保 Stub 生效：
// mainModule.js
const functionModule = require('./functionModule');
module.exports = (param1, param2) => {
// 注意：原代码中使用了未定义的变量 'argument'，此处修正为实际参数
const somethingNew = functionModule.send(param1); // 显式调用 .send()
return { somethingNew };
};✅ 步骤三：编写高可靠性测试用例
使用 sinon.stub() 替换依赖模块的指定方法，并验证调用次数与参数：
// mainModule.test.js
const mainModule = require('../mainModule');
const functionModule = require('../functionModule'); // 必须独立引入被 Stub 的模块
const sinon = require('sinon');
const { expect } = require('chai');
describe('test mainModule', () => {
it('should call functionModule.send() exactly once', () => {
// 1. 创建 Stub：替换 functionModule.send，返回可控值
const stubSend = sinon.stub(functionModule, 'send').returns('mocked-result');
// 2. 执行被测函数（注意传入真实参数，避免 ReferenceError）
const arg1 = 'test-param';
const arg2 = 42;
mainModule(arg1, arg2);
// 3. 断言：验证调用行为（推荐使用 calledOnce，语义明确）
expect(stubSend.calledOnce).to.be.true;
expect(stubSend.firstCall.args[0]).to.equal(arg1); // 可选：验证参数传递正确
// 4. 清理：恢复原始方法（重要！避免测试污染）
stubSend.restore();
});
});⚠️ 关键注意事项
- 模块必须独立引入：functionModule 需在测试文件中 require 两次——一次供 Sinon Stub，一次供被测模块内部使用（Node.js 模块缓存机制保证两者指向同一对象）。
- 禁止使用 chai.spy.on() 作用于私有依赖：chai.spy.on(mainModule, 'functionModule') 无效，因 functionModule 是局部变量，非 mainModule 属性。
- 务必调用 .restore()：否则 Stub 会持续影响后续测试用例，导致不可预测的失败。
- 参数需明确定义：原问题中 argument1/argument2 未声明，会导致 ReferenceError；测试中应使用具体值初始化。
- 优先选择 calledOnce 而非 called()：前者明确表达“期望恰好调用一次”，避免因重复调用导致误判。
通过以上结构化实践，即可稳定、可维护地验证模块间函数调用关系，显著提升测试覆盖率与协作逻辑的可信度。
