首页 > 文章 > 前端

如何设计可测试的JavaScript模块？

时间：2025-11-20 13:45:06 256浏览收藏

大家好，我们又见面了啊~本文《如何设计可测试的JavaScript模块？》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

答案：通过依赖注入将外部依赖显式传入模块，避免硬编码，提升可测试性与可维护性。例如使用函数参数或构造函数传入依赖，支持模拟替换；允许默认值但保持可覆盖，确保模块行为可控，便于单元测试和环境复用。

如何设计一个可测试的、依赖注入清晰的JavaScript模块？

设计一个可测试且依赖注入清晰的 JavaScript 模块，关键是将功能逻辑与外部依赖解耦，通过显式传入依赖来提升模块的灵活性和可维护性。这样不仅便于单元测试，也更容易在不同环境中复用。

使用函数参数进行依赖注入

最直接的方式是通过函数参数传入依赖。这种方式让调用方完全控制依赖实例，便于替换模拟对象进行测试。

例如，一个处理用户数据的服务可能依赖 API 请求模块：

function createUserService(apiClient) {
  return {
    fetchUser(id) {
      return apiClient.get(`/users/${id}`);
    }
  };
}

测试时可以轻松传入一个模拟 client：

const mockApiClient = {
get: jest.fn().mockResolvedValue({ id: 1, name: 'Alice' })
};

const userService = createUserService(mockApiClient);
await userService.fetchUser(1);
expect(mockApiClient.get).toHaveBeenCalledWith('/users/1');

保持模块纯净，避免内部硬编码依赖

避免在模块内部直接导入或实例化具体依赖，比如不要这样做：

// 不推荐
import axios from 'axios';

function fetchUser(id) {
return axios.get(`/users/${id}`); // 硬编码依赖
}

这会让测试必须真实发起网络请求，或者打桩（monkey patch）第三方模块，增加复杂度和不稳定性。应始终通过参数接收依赖。

使用类构造函数注入依赖

如果偏好面向对象风格，可以在类的构造函数中注入依赖：

class UserService {
  constructor(apiClient) {
    this.apiClient = apiClient;
  }

  async fetchUser(id) {
    const response = await this.apiClient.get(`/users/${id}`);
    return response.data;
  }
}

测试方式与工厂函数类似，只需传入模拟对象即可隔离外部影响。

提供默认值时保持可覆盖性

有时希望模块有合理的默认行为，但仍允许替换依赖。可以在参数中提供默认值，但确保外部仍能传入自定义实现：

function createLogger(outputStream = console) {
  return {
    log(message) {
      outputStream.log(`[LOG] ${message}`);
    }
  };
}

生产环境使用默认 console，测试时传入数组或 mock 对象捕获输出。

基本上就这些。只要把依赖当作输入处理，不隐藏在模块内部，测试就会变得简单可靠。结构清晰了，协作和维护也更顺畅。

到这里，我们也就讲完了《如何设计可测试的JavaScript模块？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！