获课：xingkeit.top/16341/

用对学习方法，前端单元测试少走 80% 弯路

在前端开发的技能树里，有一个知识点让很多人又爱又恨——单元测试。

爱它的人说：有了单元测试，重构代码再也不慌了，提测质量高了，半夜被叫起来修Bug的次数少了。恨它的人说：写业务代码都来不及，还要写测试？一跑全是红，根本不知道从哪开始改。

更扎心的是：很多前端开发者尝试学过单元测试，但学着学着就放弃了。不是不想学，而是方法不对，走了一大堆弯路——要么一上来就被各种工具配置搞晕，要么对着空白的测试文件不知道测什么，要么写出来的测试一跑就挂，连错在哪都看不懂。

其实，前端单元测试没那么难。用对方法，可以少走80%的弯路。这篇文章不教具体的代码，而是给你一条清晰的学习路径，让你知道“先学什么、后学什么、重点练什么”。

一、弯路一：一上来就折腾工具链

很多人的第一个弯路，是把时间花在了“配环境”上。

Jest、Mocha、Chai、Sinon、Enzyme、Testing Library……光是这些名字就能让人眼花缭乱。再加上Webpack配置、Babel转译、ESModule兼容，折腾半天，测试框架还没跑起来，热情已经耗光了。

正确做法：从“开箱即用”开始

别一上来就自己搭。现在的主流框架都提供了开箱即用的测试支持：

• Vue项目：用Vue CLI创建项目时，直接勾选Unit Testing，它会帮你配好Jest或Mocha

• React项目：用Create React App创建的项目，自带了Testing Library，直接跑npm test就能看到示例

• Next.js/Nuxt.js：官方文档里都有现成的测试配置指南，复制粘贴就能用

先把“跑起来”作为第一目标，哪怕只是跑通一个官方的示例测试文件，也比卡在配置阶段强一百倍。工具是服务于学习的，不是用来消耗学习热情的。

二、弯路二：不知道测什么

工具跑通了，打开一个空白的测试文件，很多人又开始迷茫了：我到底要测什么？

是把所有函数都测一遍？还是只测核心逻辑？组件里的交互要不要测？用户的点击行为怎么模拟？

正确做法：从“纯函数”开始练习

别一上来就测组件。组件涉及渲染、交互、异步、状态管理，干扰因素太多。先从最纯粹的工具函数开始：

• 写一个formatDate函数，给它不同的日期输入，断言输出是否符合预期

• 写一个validateEmail函数，测各种邮箱格式的验证结果

• 写一个calcTotalPrice函数，测试不同商品组合的金额计算

这些函数没有UI、没有副作用、输入输出明确，是练习单元测试的“新手村”。在这里，你能学会：

• 如何用test或it组织用例

• 如何用expect和匹配器做断言

• 如何用describe分组管理

• 如何测试边界条件和异常情况

把纯函数测熟练了，再进入下一关。

三、弯路三：不敢动组件

练熟了纯函数，接下来要面对真正的挑战——组件测试。很多人到这里又卡住了：组件里有用到props、有用户点击、有异步请求、有路由跳转，这怎么测？

正确做法：分层击破，先测“渲染”再测“交互”

第一层：测渲染
给定特定的props，组件是不是渲染出了正确的内容？

• 传一个name="张三"，页面上有没有显示“欢迎你，张三”

• 传一个list={[]}，空状态组件有没有显示“暂无数据”

• 传一个status="error"，有没有出现红色的错误提示

这一层用快照测试或DOM断言都能实现，重点是学会用代码描述“页面应该长什么样”。

第二层：测交互
模拟用户点击、输入、提交，看组件的行为是否符合预期。

• 点击按钮，某个状态变了没有

• 输入框里打字，绑定的数据有没有更新

• 提交表单，预设的回调函数有没有被调用，参数对不对

这一层需要学会模拟事件和断言函数调用。不用急着把所有交互都测全，先测最核心的几个。

第三层：测异步
组件里发了请求，怎么测？用Mock模拟API响应，不真的发请求，只测“请求发出后UI的变化”。

• 点击加载按钮，出现loading状态

• 请求成功，数据渲染出来

• 请求失败，显示错误信息

这一层要学会Mock工具和异步测试的写法。先把成功和失败两条路径覆盖到，就算入门了。

四、弯路四：忽视测试替身（Mock）

写测试时，总会遇到一些“不好测”的东西：网络请求、定时器、浏览器API、第三方库。很多人硬着头皮去真实调用，结果测试又慢又不稳定。

正确做法：学会“造假”

测试的核心原则是：只测自己写的代码，不测别人的代码和外部环境。

• 发请求的axios，用Mock模拟返回数据，不真的发HTTP

• 定时器setTimeout，用Mock让时间“快进”，不等真实时间

• localStorage，用Mock模拟存取值，不碰真实浏览器

这叫测试替身。学会它，你就能把被测代码从复杂的环境中隔离出来，只测它本身的逻辑。

学习方法：找一篇“Jest Mock入门”的文章，跟着例子把常见的Mock场景练一遍。会了Mock，组件测试的难度直接下降一半。

五、弯路五：追求覆盖率100%

有些人写着写着，开始盯着覆盖率数字：语句覆盖90%、分支覆盖85%、函数覆盖100%……为了凑覆盖率，开始写一些没意义的测试，比如测试getter函数有没有被调用、测试某行代码有没有执行。

正确做法：关注核心逻辑，放弃“为测而测”

单元测试的价值是保障核心逻辑的正确性，不是凑数字。一个健壮的测试用例，比十个凑数的测试有价值得多。

• 核心业务逻辑：必须覆盖各种分支

• 边界条件和异常场景：必须覆盖

• 工具函数和公共方法：尽量覆盖

• 简单的UI展示、常规的getter/setter：可以放过

覆盖率是参考，不是目标。等你把核心逻辑测稳了，覆盖率自然就上去了。

六、弯路六：只学不用

最后一条弯路，也是最常见的：学完就忘。

看了视频、读了文章、跟着敲了例子，然后项目里一忙，就把单元测试抛在脑后。三个月后再想写，全忘了。

正确做法：马上用，持续用

最好的学习方法，是在你正在开发的项目里写测试：

• 新写一个工具函数，顺手把测试写了

• 改一个老组件，顺手给核心逻辑加个测试

• 修一个Bug，先写一个重现Bug的测试，再改代码

一次写一点，积少成多。当测试成为开发流程的一部分，而不是额外任务时，你才真正学会了。

七、结语

前端单元测试不是天赋，是技能。只要方法对，每个人都能学会。

• 从开箱即用的工具开始，不折腾配置

• 从纯函数开始，不急着测组件

• 分层击破组件测试，先渲染后交互

• 学会Mock，隔离外部依赖

• 关注核心逻辑，不追求无效覆盖率

• 在真实项目里持续练习

用这套方法，你可以绕过80%的弯路，直接进入“会写、敢写、愿意写”的正循环。

当你不再害怕重构代码，当提测时再也不用提心吊胆，当别人还在为线上Bug焦头烂额时，你已经在悠闲地喝茶——你会感谢当初那个认真学单元测试的自己。