具备C#/Java OOP背景如何编写TypeScript可测试函数式代码？

你提出的给函数增加默认入参注入依赖的方案是完全可行的，这是函数式代码实现依赖注入最轻量化的实现方式之一，业务侧原有调用逻辑不需要任何改动，测试时只需传入你 mock 好的 LocalForage 实例即可完成依赖替换，类型安全也能得到保障。该方案唯一的缺点是当同模块下 CRUD 函数数量较多时，每个函数都需要重复声明相同的依赖参数，后续新增依赖时需要批量修改所有函数，维护成本偏高。

其他可选重构方案 #

方案1：工厂函数批量生成带依赖的方法集 #

如果同个模块下的多个函数都依赖同一个外部实例，可以用高阶工厂函数统一注入依赖，一次性生成所有关联方法，避免重复代码：

// 工厂函数，接收依赖实例作为入参
export const createFooCrud = (storage: LocalForage) => {
  const addFoo = async (foo: Foo): Promise<void> => {
    await storage.setItem(foo.id, foo);
  };
  const getFoo = async (id: string): Promise<Foo | null> => {
    return storage.getItem(id);
  };
  // 其余CRUD方法统一在这里实现
  return { addFoo, getFoo /* 其余方法导出 */ };
};

// 业务侧默认导出用全局配置生成的实例，原有调用逻辑无需改动
const defaultFooStorage = createInstance({/* 原有配置 */});
export const fooCrud = createFooCrud(defaultFooStorage);

测试时只需传入 mock 好的 LocalForage 实例调用工厂函数，就能得到所有依赖替换完成的测试用方法集，和 OOP 构造注入的体验完全一致，同时保留了函数式的写法。

方案2：测试框架模块级Mock（无需改动业务代码） #

如果不想调整现有业务代码，可以利用测试框架的模块Mock能力直接替换硬编码的依赖实例，以Jest为例：

// 测试文件内的mock逻辑
jest.mock('./your-module-path', () => {
  const originalModule = jest.requireActual('./your-module-path');
  // 替换模块内的私有fooStorage实例为mock对象
  const mockStorage = {
    setItem: jest.fn().mockResolvedValue(undefined),
    getItem: jest.fn().mockResolvedValue(null)
  };
  return { ...originalModule, fooStorage: mockStorage };
});

该方案的优势是完全不需要修改业务代码，缺点是强依赖测试框架的能力，复杂mock逻辑的维护成本较高，且容易出现类型不匹配的问题。

Axios、Zustand同类问题的解决方案 #

Axios封装函数处理 #

• 显式注入方案：封装请求工厂函数，接收Axios实例作为入参，返回所有封装好的业务请求方法，默认导出用全局配置Axios实例生成的请求集合，测试时传入mock的Axios实例即可。
• 快速方案：测试时直接mock axios.get/axios.post 等核心方法，或者mock你封装的全局Axios实例模块。

Zustand封装函数处理 #

• 显式注入方案：将store作为工具函数的最后一个可选默认参数，默认值导入全局store实例，测试时传入独立创建的测试用store即可。
• 工厂方案：如果是批量的store操作函数，同样可以用工厂函数接收store实例，返回所有操作方法。
• 测试时也可以直接调用Zustand的create方法生成独立的测试用store，和全局store完全隔离，避免状态污染。

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