当前位置：首页 > 文章列表 > 文章 > 前端 > 如何测试JavaScript代码的可靠性_JavaScript单元测试框架有哪些选择

如何测试JavaScript代码的可靠性_JavaScript单元测试框架有哪些选择

2026-02-06 11:28:06 0浏览收藏

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《如何测试JavaScript代码的可靠性_JavaScript单元测试框架有哪些选择》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

Jest 更适合中大型长期维护项目，Vitest 更适合新项目和 Vite 生态；两者均需正确配置以避免模块解析错误，可靠测试需覆盖边界、隔离副作用、验证行为而非实现细节。

用 Jest 还是 Vitest 测 JavaScript 单元测试？

Jest 仍是当前最成熟的 JavaScript 单元测试框架，但 Vitest 正在快速成为更轻量、更快启动的替代选择。两者都支持 describe、it、expect 语法，但底层差异明显：Jest 自带模拟（mock）系统和快照机制，Vitest 则复用 Vite 的模块解析与 HMR，对现代前端项目（尤其含 ESM、TS、Vue/React）启动速度更快。

常见错误现象：Jest encountered a declaration exception 往往因 jest.config.js 中 transform 配置未覆盖 .ts 或 .jsx 文件；Vitest 报 Cannot find module 'vue' 多因未在 vitest.config.ts 中配置 resolve.alias。

Jest 更适合需要完整隔离环境、大量定时器/网络 mock、长期维护的中大型项目
Vitest 更适合新项目、Vite 生态、追求本地开发时秒级测试反馈的团队
两者都不直接支持浏览器 DOM 操作测试——需搭配 @testing-library/dom 或 jsdom 环境

如何写一个真正可靠的 `test` 函数断言？

可靠不等于“能跑通”，而在于是否覆盖边界、是否隔离副作用、是否验证行为而非实现细节。比如测试一个 sum(a, b) 函数，只写 expect(sum(1, 2)).toBe(3) 是脆弱的；它没验证 null、undefined、NaN、大数溢出或非数字输入的行为。

实操建议：

每个 it 只测一个明确行为，名称用 “should … when …” 句式，如 should return 0 when both args are null
对函数参数做类型校验的，必须显式测试 sum(null, 1)、sum('1', 2) 等非法输入路径
避免在测试中调用真实 API 或读写本地存储——用 jest.mock() 或 vi.mock() 替换依赖
慎用 toBe 比较对象或数组，优先用 toEqual；对异步操作，必须 await 或返回 Promise

`beforeEach` 和 `jest.resetModules()` 为什么经常一起用？

因为 ES 模块默认单例缓存，多次 import 同一模块不会重新执行顶层代码——这会让 mock 失效或状态残留。例如你在测试中用 jest.mock('./api') 模拟了请求函数，但下一个测试仍可能拿到上一个测试里被修改过的模块实例。

解决方法是每次测试前重置模块缓存：

beforeEach(() => {
  jest.resetModules();
});

it('calls api with correct token', () => {
  const mockFetch = jest.fn().mockResolvedValue({ json: () => ({ ok: true }) });
  jest.mock('./api', () => ({
    fetchUser: mockFetch
  }));

  // 此处 import 必须在 mock 之后、且在 beforeEach 重置后
  const { getUser } = require('./user-service');
  getUser('123');

  expect(mockFetch).toHaveBeenCalledWith('123', 'token-abc');
});

注意：require 动态导入 + jest.resetModules() 是关键组合；ESM 中若用 import 语句则无法在运行时控制加载时机，此时推荐改用 vi.mock()（Vitest）或提前在 setupFilesAfterEnv 中统一 mock。

测试覆盖率高 ≠ 代码可靠，哪些地方最容易被忽略？

行覆盖率（% lines）常掩盖逻辑漏洞。比如一个 if (a > 0 && b 条件，只测 a=5, b=5 和 a=-1, b=5 能达到 100% 行覆盖，但漏掉了 a=5, b=15（第二个条件为 false）和 a=-1, b=15（两个都 false）——这就是分支覆盖率缺失。

容易被忽略的点：

异步错误处理：比如 try/catch 块中 reject 是否被正确捕获，catch 分支是否真被执行
事件监听器注册/销毁：组件卸载时是否清理了 addEventListener 或定时器，否则导致内存泄漏或误触发
第三方库副作用：如调用 localStorage.setItem 后未清理，影响后续测试
时序敏感逻辑：如 setTimeout、Promise.resolve().then()，需用 jest.useFakeTimers() 或 vi.runOnlyPendingTimers() 控制