当前位置：首页 > 问答 > 正文

前端单元测试那些事儿，聊聊怎么写出靠谱又高效的测试代码

瞿欣合
问答
2026-01-11 04:54:53
3

根据多位资深前端开发者在社区分享的经验、博客文章以及常见测试框架官方文档的实践建议综合整理）

前端单元测试那些事儿,聊聊怎么写出靠谱又高效的测试代码

咱们做前端开发的,经常聊到一个话题就是单元测试，很多人觉得它麻烦，写了代码还要再写测试，感觉是额外的工作量，也有人觉得它很重要，是保证代码质量的护城河，今天咱就不扯那些大道理，就聊聊在实际项目中，怎么把单元测试写得既靠谱，让人放心，又高效，不占用太多时间。

心态先摆正：测试不是负担，是“安全网”和“说明书”

首先得想明白为啥要写测试,它真不是为了应付公司流程，你想想，当你修改一个很久没碰的、非常复杂的函数时，你慌不慌？生怕一不小心改出个bug来，但如果你为这个函数写了完善的单元测试，你改完之后，只需要跑一遍测试用例，如果测试全绿（通过），你心里就特别有底，这就是“安全网”的作用。

一个好的测试用例,其实就是一段活生生的代码使用范例，一个新同事接手你的模块，他可能看不懂你写的复杂逻辑，但他能看懂测试用例里输入是什么，期望输出是什么，这比写一大堆注释管用多了，测试就是最准确的“说明书”。

写什么？别瞎测，抓住重点

不是所有代码都值得写单元测试,你要是给一个简单的加法函数写测试，那纯属浪费时间，我们的时间要花在刀刃上。

核心业务逻辑：这是重中之重，比如计算订单金额的函数、处理用户权限的逻辑、数据格式转换的工具函数等，这些地方一旦出错，直接影响用户和业务，必须重点覆盖。
复杂的工具函数/公共组件：那些被很多地方复用的函数和组件，它们就像房子的承重墙，这里塌了，整个项目都可能受影响，给它们写好测试，受益的是整个团队。
容易出错的边界情况：人脑容易忽略边界，函数参数传了null、undefined、空数组、非常长的字符串会怎么样？这些边界情况正是测试大显身手的地方，你没想到的，测试能帮你想到。

反过来,下面这些情况可以少写或者不写：

简单的UI组件的渲染（比如就显示一段文字），这种测试价值不大，可以用更粗粒度的E2E测试覆盖。
第三方库的功能,人家库的作者已经测试过了，你再测一遍是重复劳动。

怎么写？记住这几个实用技巧

光知道测什么还不够,怎么写得好才是关键。

起个好名字：测试用例的名字要像说人话一样，清晰表达测试的意图，别用test1、test2这种，好的名字比如：“当传入有效用户名和密码时，应该返回登录成功”，“当购物车为空时，总金额应该显示为0”，这样一旦测试失败了，你一眼就能看出是哪个功能点出了问题。
3A原则（Arrange-Act-Assert）：这是写测试的一个经典结构，能让你的测试代码条理清晰。
- Arrange（准备）：准备好测试所需要的数据和环境，创建一个待测试的函数实例，构造一些模拟的输入数据。
- Act（执行）：调用你要测试的那个函数或方法，传入准备好的数据。
- Assert（断言）：断言执行的结果是否符合你的预期。
举个例子,测试一个计算价格的函数：
```
test(‘当购买3件单价10元的商品时，总价应为30元’, () => {
  // Arrange: 准备数据
  const quantity = 3;
  const price = 10;
  // Act: 执行函数
  const total = calculateTotal(quantity, price);
  // Assert: 断言结果
  expect(total).toBe(30);
});
```
这样结构非常清晰,别人一看就懂。
模拟（Mock）掉一切外部依赖：单元测试的核心是“单元”，意思是只测试当前这一小块代码的逻辑，如果你的函数内部调用了API接口、读了本地存储（localStorage）、或者用了其他模块，你要把这些“外部依赖”模拟掉，用一个模拟函数（Mock Function）代替真实的API调用，直接返回你预设好的数据，这样做的好处是：
- 测试速度快：不需要等真实的网络请求。
- 结果稳定：不会因为网络波动或服务器挂掉而导致测试失败。
- 聚焦自身逻辑：你测试的只是这个函数如何处理返回值，而不是API本身对不对。
一个测试只测一件事：不要把好几个测试点塞到一个测试用例里，如果一个测试失败了，你应该能立刻知道是哪个具体功能点出了问题，如果一个大测试包含了五件事，一旦失败，你还得花时间去排查到底是哪一部分的逻辑错了。