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、大数溢出或非数字输入的行为。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每个
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()控制
真正影响可靠性的，往往不是“有没有测试”，而是“有没有测对路径”和“有没有切断外部干扰”。
