JavaScript/TypeScript TDD单元测试模块函数访问与导出最佳实践

1. 单元测试访问模块内所有JS/TS函数的可接受方案 #

• 通过公开API覆盖内部逻辑：如果内部函数func2是公开导出的func1的依赖项，优先通过设计func1的测试用例覆盖func2的所有分支逻辑，这是最符合单元测试设计原则的方案，不需要额外修改模块导出规则，也不会破坏模块封装性。
• 约定半公开内部导出对象：如果内部函数逻辑独立、确实需要单独测试，可以在模块内额外导出一个命名约定为__internal__的对象，挂载所有需要测试的内部函数。示例实现：

// Sample1.js 改造后
const func1 = () => {
    //code that does stuff
    return "stuff";
};
const func2 = () => {
   //code that does other stuff
   return "otherStuff";
};
export { func1 };
// 测试专用内部导出，业务代码禁止直接调用
export const __internal__ = { func2 };

测试时直接导入该对象即可调用内部函数：

import { func1, __internal__ } from "./Sample1.js"
const { func2 } = __internal__;

// 后续正常编写func2的测试用例即可

这种方案是行业内普遍接受的测试方案，既满足测试需求，也通过明确的命名约定告知其他开发者该对象仅用于测试，不要在业务逻辑中调用。

• 使用模块注入工具：如果不想修改业务代码的导出逻辑，可以使用rewire、Jest内置的jest.mock等工具直接注入访问模块内部的未导出变量，不过这类方案需要额外的依赖配置，TS环境下还需要做额外的类型兼容处理，通用性比前两种差。

2. 不建议全量导出模块内函数的核心原因 #

• 破坏模块封装性：模块的核心设计原则就是暴露最小必要的公开API，隐藏内部实现细节。全量导出后，模块的内部实现完全对外暴露，其他开发者很可能在业务代码中直接调用原本的内部函数，导致模块和外部代码的耦合度大幅提升。
• 提升重构维护成本：正常迭代中，公开API需要保持向后兼容，而内部函数可以随时调整逻辑、入参甚至直接删除。如果全量导出所有函数，相当于所有函数都变成了公开API，后续重构时只要修改任何一个函数的逻辑，都需要排查全项目所有的调用点，维护成本会指数级上升。
• 模糊模块边界：全量导出会让其他开发者无法快速判断模块的对外能力边界，不知道哪些是官方支持的稳定接口，哪些是随时可能变化的内部实现，多人协作的项目中很容易出现不符合预期的调用，埋下技术债务。

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