JavaScript单元测试是针对函数最小可测单元的隔离验证，确保其在各种输入下返回预期结果；核心是不依赖DOM、网络等外部环境，专注逻辑正确性，常用Jest框架实现断言、mock和异步测试。
JavaScript 中的单元测试，就是针对函数（或模块）的最小可测单元，单独验证它在各种输入下是否返回预期结果。核心是“隔离”——不依赖外部环境（如 DOM、网络、数据库），只关注函数本身逻辑是否正确。
为什么需要为函数写单元测试
函数是 JS 开发中最基础、最常复用的单元。一个计算价格的函数、一个格式化日期的工具、一个校验邮箱的正则封装……如果它们出错，可能影响多个页面或功能。单元测试能：
- 快速发现修改引发的意外问题（比如重构后逻辑变错）
- 明确函数的输入边界和行为（比如空字符串、负数、null 怎么处理）
- 让别人（或未来的你）放心调用这个函数——有测试兜底，就知道它“承诺过什么”
用 Jest 写一个
简单函数的测试（推荐入门）
Jest 是目前最主流的 JS 单元测试框架，零配置起步快，断言清晰，还自带模拟（mock）能力。假设我们有一个加法函数：
function add(a, b) { return a + b; }
对应的测试文件（比如 add.test.js）可以这样写：
test('add 函数应正确返回两数之和', () => {
expect(add(2, 3)).toBe(5);
expect(add(-1, 1)).toBe(0);
expect(add(0.1, 0.2)).toBeCloseTo(0.3); // 浮点数用 toBeCloseTo
说明：
-
test() 定义一个测试用例，第一个参数是描述性文字，第二个是执行断言的函数
-
expect(...).toBe(...) 是断言：检查实际值是否严格等于预期值
- 浮点运算有精度误差，所以 0.1 + 0.2 !== 0.3，要用 toBeCloseTo 判断近似相等
覆盖常见边界情况（不只是“正常值”）
好测试不是只测“对的输入”，更要测函数如何应对异常或边缘场景。比如改进上面的 add，让它更健壮：
function add(a, b) {
if (typeof a !== 'number' || typeof b !== 'number') {
throw new TypeError('参数必须是数字');
}
return a + b;
}
对应测试就该包含：
- 正常数字：expect(add(1, 2)).toBe(3)
- 零和负数：expect(add(0, -5)).toBe(-5)
- 错误类型：expect(() => add('1', 2)).toThrow('参数必须是数字')
- undefined 或 null：expect(() => add(null, 2)).toThrow()
这些不是“找茬”，而是帮你在函数接口层面定义清楚——它接受什么、拒绝什么、抛什么错。
测试异步函数（比如 fetch 封装）
现代 JS 大量使用 Promise。假设你写了这样一个获取用户姓名的函数：
async function fetchUserName(userId) {
const res = await fetch(`/api/users/${userId}`);
const data = await res.json();
return data.name;
}
直接调用真实 API 不适合单元测试（慢、不可控、依赖网络）。Jest 提供 mock 功能来“替换” fetch：
global.fetch = jest.fn(() =>
Promise.resolve({
json: () => Promise.resolve({ name: 'Alice' })
})
);
test('fetchUserName 应返回用户姓名', async () => {
const name = await fetchUserName(123);
expect(name).toBe('Alice');
expect(fetch).toHaveBeenCalledWith('/api/users/123');
});
关键点：
- 用 jest.fn() 模拟 fetch 行为，控制返回值
- 测试函数要声明为 async，并用 await 等待结果
- 还能验证 fetch 是否被正确调用（参数对不对），这是“行为测试”
基本上就这些。写单元测试不复杂，但容易忽略——真正价值不在“跑通”，而在让函数行为变得可预期、可维护、可信任。
简单函数的测试（推荐入门）