1. 单元测试到底是什么东西先说个我自己的真实经历。有一次改了一个支付金额的格式化函数改完自信满满地提交了代码结果第二天测试就报了两个用例失败。我当时还挺不服气——明明功能看起来正常直到我仔细查了用例才发现我把小于 1 元时的进位逻辑写反了。要不是那两条单元测试用例在那里挡着这个 bug 就会直接漏到线上后面影响的是真实订单和真金白银。从那以后我就把单元测试当成开发流程里一道默认工序跟写完代码要顺手格式化一样自然。1.1 一个单元到底有多大很多人对单元测试的第一反应是那不就是写点测试代码吗对但不完全对。这里最关键的词其实是单元两个字。所谓单元指的是代码里最小的、可独立验证的逻辑片段。往细了说它可以是一个函数、一个方法再大一点它可以是一个组件、一个类但前提是这个单元自己能够被单独拿出来运行。它不需要数据库真的连着不需要 Redis 真的开着不需要依赖的线上服务真的返回数据——只要把这个单元放进测试环境里给它喂入参数观察它的返回值或者行为变化这事儿就成了。我用一个生活化的类比解释一下。想象一下你组装一台电脑你会先单独测电源能不能通电单独测内存条能不能被识别单独测显卡能不能输出画面最后才会把他们装到机箱里整机点亮。单元测试就好比是在组装之前先把每个零件单独测一遍。整机测试当然也要做但等整机点不亮的时候再去排查到底是哪个零件坏了成本就高得多了。很多人会纠结一个函数算单元那一个组件算不算我的经验是只要满足两个条件就可以当单元来测第一它自己可以脱离外部环境独立运行第二测试它的时候我们只需要关心它内部的输入输出逻辑。至于是函数还是组件还是方法其实无所谓关键是粒度不要大到牵扯进多个模块的交互。一旦你的单元测试开始需要数据库、需要登录态、需要一堆 Mock 服务那它就不是单元测试了那是集成测试。1.2 为什么单元测试不是额外负担一提单元测试很多人的第一反应是又要多写不少代码项目进度本来就紧哪还有时间写测试业余时间写多了就会发现这个想法里隐藏着一个误解你把写单元测试当成了一种额外开销但实际上它是在帮你降低整个开发周期里的总开销。你写测试花掉的 30 分钟很可能省掉的是后面改 bug、走查、联调、回归测试的 3 个小时。尤其在需求频繁变动的业务项目里改动一个公共函数你不知道它会波及哪些模块这时候单元测试就是你手里唯一一张安全网。而且单元测试还有一个特别容易被低估的作用它其实是代码设计质量的度量尺。当你发现一个函数特别难写测试的时候八九不离十这个函数本身的设计就有问题——职责不单一、隐式依赖太多、耦合度太高。所以有人把测试难写当成重构的信号这个思路我是比较认同的。能轻松写测试的代码通常结构也差不到哪里去。2. 单元测试到底有什么用不只是在改bug单元测试有什么用这个问题我认真想过很久。问这个问题的人往往是有一定开发经验、但还没有系统尝到过测试甜头的开发者。我的回答是它的作用不是靠一两个故事讲完的而是会渗透进你整个开发节奏里。2.1 先说最直接的作用回归保障所谓回归指的是你改了这段代码结果把别的地方搞坏了的情况。这是软件开发里最常见的翻车事故没有之一。我举个非常典型的例子假设你维护一个电商项目有一个计算运费的工具函数calcFreight(city, weight)。它根据城市和重量计算运费原来逻辑很简单首重 1kg 收 8 块每超 1kg 加 2 块。有一天产品经理说新疆西藏要加偏远地区附加费。你改了这个函数加了 5 行代码。不写单元测试的话你验证完新疆、西藏两个案例就提交了。但实际上运费价格的影响面远不止这两个城市——还有包邮活动、满减逻辑、会员折扣它们都可能调用这个函数。如果里面有哪层逻辑被你不小心改动到线上用户买东西的时候运费就算错了。更麻烦的是这类问题往往不是一上线就爆发的而是等某个特殊条件的订单出现时才暴露。但是如果你提前给这个函数写了 20 条测试用例覆盖首重、续重、偏远地区、特殊活动叠加等情况你改完之后跑一下测试经过的用例会告诉你这里没问题没经过的用例会精确地告诉你这两条挂了问题出在哪个分支。整个过程不超过 30 秒比你去人工点页面验证快十倍都不止。所以我一直有一个观点追求代码覆盖率不是目的追求每次改动都有快速反馈才是目的。覆盖率再高的测试如果跑一轮要半小时开发者一天跑不了几次那它的价值就大打折扣了。2.2 单元测试逼迫你写出更好的代码这个作用我前面提了一句但它值得单独展开说。写单元测试的时候你会不自觉地开始审视自己的代码这个函数的参数是不是太多了这个判断条件是不是太复杂了这个函数里是不是偷偷用了全局变量因为有了测试这个第三视角你会开始主动把纯逻辑抽离出来把副作用隔离开把依赖注入进去。时间长了你的代码会越来越倾向于模块化、可测试化这本身就是代码质量提升的过程。我自己最明显的体会是开始大量写单元测试之后我写代码时的下意识动作变了。以前写一个工具函数想到哪写到哪写完了再倒回去看有没有问题。现在写函数的时候脑子里会先过一个念头这个输入传进来应该返回什么如果传一个空值呢如果传一个超长字符串呢这些边界情况在写代码的时候就埋进去了后面再写测试用例只是把它们显式化而已。这就是所谓的测试思维反向驱动开发。2.3 对团队协作的价值让新人敢改代码还有一个作用特别实际但对团队的意义非常大单元测试能让新人在接手项目时敢动代码。我见过太多的新人入职之后接手老项目想改一个功能试探性地问了问老同事这个函数我改一下没问题吧老同事想了想说应该没问题你改吧。然后新人改了上线出 bug背锅的还是新人。问题出在哪不是人的能力问题而是这个项目没有测试保护网。谁都不敢说自己改完一定不影响其他逻辑只能靠经验和胆量硬扛。但如果这个模块有一套完整的单元测试新人改完代码跑一遍测试绿了就可以相对放心地提交挂了测试会告诉他具体是哪里没考虑到。这不只是对新人友好对整个团队的交付质量都是强有力的支撑。所以我自己带团队的时候对公共模块和核心业务逻辑单元测试是硬性要求不是可选项。3. 一个真实可复现的单元测试项目长什么样前面讲了这么多理论和价值不写点实操总觉得少了点什么。这一节我拿一个 Vue 项目来做个演示因为前端单元测试近几年的热度和复杂度都在上涨而且vue单元测试报错这个词也说明大家实际动手时遇到的坑不少。我会把这个过程写得尽量详细你可以照着操作一遍。3.1 环境与工具选型先说工具。Vue 生态里目前主流的单元测试方案是 Vitest vue/test-utils这个组合的体验比老一代的 Jest Vue Test Utils 要好太多。Vitest基于 Vite 的测试框架启动快、语法简单、支持热更新和 Vite 工程无缝整合。vue/test-utilsVue 官方提供的组件测试工具库可以挂载组件、触发事件、模拟 props、查询 DOM 元素。如果项目本身就是 Vite 脚手架创建的加这两个依赖基本零成本npm install -D vitest vue/test-utils jsdom安装完成后需要在vite.config.js里加一段测试配置/// reference typesvitest / import { defineConfig } from vite; import vue from vitejs/plugin-vue; export default defineConfig({ plugins: [vue()], test: { environment: jsdom, globals: true } });这里解释几个关键配置的含义environment: jsdom告诉 Vitest 模拟一个浏览器 DOM 环境。因为组件测试要挂载 DOMNode.js 环境本身没有document和window需要 jsdom 来模拟。globals: true开启之后可以直接使用describe、it、expect这些全局方法不用在每个测试文件里手动 import。然后在package.json里加一个脚本{ scripts: { test: vitest, test:run: vitest run } }vitest开启的是 watch 模式文件有改动会自动重跑vitest run是跑完即退出适合 CI 环境使用。提示如果项目 Vue 版本是 2.x那测试方案会不一样常用的组合是vue/test-utils1 Jest。这里有版本兼容问题装错版本很容易出现奇怪报错。3.2 从零开始给一个 Vue 组件写单元测试我准备了一个非常简单的组件一个计数器template div classcounter p classcount{{ count }}/p button classincrement clickincrement1/button button classdecrement clickdecrement-1/button /div /template script setup import { ref } from vue; const props defineProps({ initialCount: { type: Number, default: 0 } }); const count ref(props.initialCount); function increment() { count.value 1; } function decrement() { count.value - 1; } defineExpose({ count, increment, decrement }); /script现在我们来写它的单元测试。在src下建一个__tests__目录新建Counter.spec.jsimport { describe, it, expect, beforeEach } from vitest; import { mount } from vue/test-utils; import Counter from ../components/Counter.vue; describe(Counter 组件, () { let wrapper; beforeEach(() { wrapper mount(Counter, { props: { initialCount: 10 } }); }); it(初始值应该等于传入的 initialCount, () { const countText wrapper.find(.count).text(); expect(Number(countText)).toBe(10); }); it(点击 1 按钮后数字增加 1, async () { await wrapper.find(.increment).trigger(click); const countText wrapper.find(.count).text(); expect(Number(countText)).toBe(11); }); it(点击 -1 按钮后数字减少 1, async () { await wrapper.find(.decrement).trigger(click); const countText wrapper.find(.count).text(); expect(Number(countText)).toBe(9); }); });保存之后终端跑一下npm run test:run会看到类似下面的输出Test Files 1 passed (1) Tests 3 passed (3)三条用例全绿意味着这个组件的基本交互逻辑被验证过了。你可能觉得这个例子太简单了但我故意选简单例子是想让你先跑通最基础的流程。真实项目里的组件无非是在这个基础上不断增加 props、事件、异步请求、插槽等内容而已测试的基本套路不会变挂载组件 - 找元素 - 触发事件 - 断言状态。3.3 测试异步逻辑和 Mock 依赖真实的组件几乎不可能像计数器这么简单多数情况下组件里会调用接口。这时候要用的关键技术就是 Mock。比如有个组件挂载的时候从接口拿用户列表script setup import { ref, onMounted } from vue; import { fetchUserList } from ../api/user; const users ref([]); const loading ref(false); onMounted(async () { loading.value true; try { const res await fetchUserList(); users.value res.data; } finally { loading.value false; } }); /script如果直接在单元测试里跑这个组件它会真的发起 HTTP 请求。这是单元测试的大忌因为一旦依赖真实网络测试就变得不稳定——网络超时、服务器 500、状态码不对都会让测试莫名挂掉。正确做法是用 mock 拦截这个请求import { mount, flushPromises } from vue/test-utils; import UserList from ../components/UserList.vue; import { fetchUserList } from ../api/user; vi.mock(../api/user, () ({ fetchUserList: vi.fn().mockResolvedValue({ data: [ { id: 1, name: 张三 }, { id: 2, name: 李四 } ] }) })); describe(UserList, () { it(挂载后渲染用户列表, async () { const wrapper mount(UserList); await flushPromises(); expect(wrapper.text()).toContain(张三); expect(wrapper.text()).toContain(李四); }); });这里的核心逻辑是vi.mock把fetchUserList这个模块方法替换成我们自己定义的 mock 实现它不再发真实请求而是直接返回事先准备好的数据。flushPromises的作用是等所有 Promise 状态落定确保异步更新 DOM 之后再执行断言。我每次写前端测试都坚持一个原则所有外部依赖全部 mock只把组件自身逻辑留到测试里。因为单元测试测的是这一个单元的职责如果你把外部接口、数据库、第三方 SDK 都扯进来测试的定位就跑偏了。4. 报错排查vue单元测试的那些常见坑vue单元测试报错是搜索热词说明大部分人在实际写测试时都翻过车。这一节我把最常见的问题整理出来附上排查思路方便你直接对照着处理。4.1 环境配置类报错这类报错最典型的就是document is not defined。它的原因是测试环境没有 DOM。解决方案就是前面提到的在vitest.config里设置environment: jsdom或者写文件顶部的注释指令// vitest-environment jsdom还有一类是window is not defined原因和上面一样同样是环境变量设置问题。排查的时候先看一眼报错信息里提到的是不是document/window这类浏览器对象是的话基本就是环境配置缺失。另一个常见报错是Cannot find module。比如测试文件里引入组件用的是相对路径路径写错了。排查时就去看文件路径和实际目录结构是否一致尤其是别名路径在测试环境里不一定默认被解析。解决办法是在 vite 配置里给test也同样配置别名import path from node:path; export default defineConfig({ resolve: { alias: { : path.resolve(__dirname, src) } }, test: { // 需要的时候测试里也支持 别名 resolve: { alias: { : path.resolve(__dirname, src) } } } });4.2 组件测试里最容易翻车的三个场景第一个定时器和异步更新导致断言失败。组件里用了setTimeout测试里没有等待足够时间就执行了断言。Vitest 默认是同步跑完整个测试流程的你需要用vi.useFakeTimers()配合vi.advanceTimersByTime()或者直接用真实的延时等待it(延时后出现提示, async () { const wrapper mount(Tooltip); await new Promise(resolve setTimeout(resolve, 300)); expect(wrapper.text()).toContain(提示内容); });不过我更推荐用 fake timers因为它不浪费时间it(延时后出现提示, () { vi.useFakeTimers(); const wrapper mount(Tooltip); vi.advanceTimersByTime(300); expect(wrapper.text()).toContain(提示内容); vi.useRealTimers(); });第二个组件在挂载时调用第三方库但第三方库跟 jsdom 不兼容。比如有些库用到window.matchMediajsdom 里没有这个 API测试就会直接报错。解决办法是在测试文件里手动 mock 掉它Object.defineProperty(window, matchMedia, { writable: true, value: vi.fn().mockImplementation(query ({ matches: false, media: query, onchange: null, addListener: vi.fn(), removeListener: vi.fn(), addEventListener: vi.fn(), removeEventListener: vi.fn(), dispatchEvent: vi.fn() })) });第三个样式或者静态资源导入报错。组件里直接引了.css文件或.svg图片vitest 无法解析这类非 JS 文件。解决办法是在配置文件里把这类资源转成空对象test: { server: { deps: { inline: [/\.css$/, /\.svg$/] } } }如果你用的是 Vitest 2.x 以上版本还可以用css: true来开启 CSS 解析支持不过大多数情况下我都是简单处理不测样式就完事了。4.3 统一整理一张速查表报错现象可能原因解决办法document is not defined环境未配置 jsdomvite.config 设置 test.environmentwindow is not defined环境未配置 jsdom同上或文件顶部注解Cannot find module路径错误或别名未解析检查相对路径配置别名解析[Vue warn] Failed to resolve component测试未注册全局组件在 mount 时使用 global.components 配置matchMedia is not definedjsdom 缺失该 API手动 mock window.matchMedia断言失败但开发环境正常异步状态未等待使用 flushPromises / await nextTickvi.mock没生效mock 路径与源码引入路径不一致保证 vi.mock 中路径与实际 import 一致拿不到组件实例方法script setup默认封装用 defineExpose 暴露方法后再访问注意vuevite场景下如果用的是 Jest还会遇到 ESM 转换的兼容问题。所以我现在的默认推荐就是 Vitest省心很多报错也和 Vite 生态同源排查起来更容易。5. 基于LLM的单元测试把 AI 塞进测试流程里最近有个趋势值得聊一下——基于 LLM 的单元测试。简单说就是利用大语言模型来自动生成单元测试用例。坦白讲我第一次听说这个方向的第一反应是AI 写测试靠谱吗我自己真正试过一轮之后态度转变为值得关注但离完全替代人工还有距离。5.1 为什么 LLM 特别适合生成单元测试理由其实不复杂。LLM 在代码理解、模式识别方面的能力天然适配给定代码、产出测试代码这个任务。单元测试本身就是一种相对模板化的代码结构——定义测试套件、构造输入、模拟依赖、断言结果。它不像业务逻辑那样充满了各种模糊的需求分歧它的目标相当明确让被测代码的行为变得可观测、可验证。我用过几个方向的产品和工具包括一些开源方案和商业插件。说一个让我印象深刻的体验把一个几百行的工具函数丢给 LLM它生成的测试用例不仅覆盖了正常输入还自动想到了空数组、null、超大数字、负值这些边界情况。这些正是我平时最容易漏掉的场景AI 反而会很规范地列出来。这一点上LLM 的价值是超出预期的。另外一个特别适合 LLM 的场景是存量代码测试补全。很多老项目历史包袱重模块一直没有单元测试覆盖。如果让人手动补测试成本非常高兴趣也很难维持。但把代码交给 LLM 批量生成一个基础测试骨架人工再逐个检查、调整、补充边界效率会高很多。我实测下来一个中等复杂度的工具模块从零开始写测试可能要 40 分钟用 LLM 辅助生成再人工修改15 分钟基本能搞定。5.2 我用 LLM 辅助写单元测试的实际路径方法很简单但里面有一些细节需要注意。我直接给一套可以复用的 prompt 模板你是一名前端测试工程师请为我下面的组件/函数生成单元测试。要求使用 Vitest 和 vue/test-utils覆盖正常路径、边界情况、异常情况不发起真实网络请求使用 vi.mock 模拟断言要具体不能只写toBeTruthy先输出测试文件再输出运行测试可能遇到的问题之后把源码粘贴进去再把项目相关上下文比如依赖环境、数据接口返回格式一并提供给 LLM生成结果后逐条审查。我自己踩过这几次坑之后总结出一套检查清单断言质量AI 经常会生成expect(fn).toBeTruthy()这种含糊断言要手动改成toBe(10)、toHaveLength(2)这种精确断言。mock 是否合理AI 生成的 mock 数据往往过于完美真实接口返回的数据结构更复杂。手动检查 mock 数据字段是否与真实接口对齐。是否测到行为要关注交互行为有没有被验证到而不只是组件渲染出静态文本。5.3 你会踩到的生成质量坑这里必须说点泼冷水的话。LLM 生成的单元测试问题没那么少你需要清醒看待。第一幻觉式 API。LLM 会编造不存在的 API 或方法。比如它可能假装你这个工具函数里有一个setConfig方法实际上根本不存在。测试跑起来直接报TypeError: xxx is not a function。所以生成的测试必须实际跑一遍不能只看代码觉得没问题。第二覆盖率虚高但实际价值低。AI 生成的测试可能全部通过但覆盖率报告很漂亮实际断言的是无关紧要的东西。比如只测试一个 getter 是否返回定义好的常量这种测试意义接近于零。判断测试价值的标准只有一个如果被测代码的业务逻辑错了这个测试能不能抓住抓不住就是垃圾测试。第三测试的脆弱性。AI 生成的测试经常会写死 DOM 结构比如wrapper.find(div div p)。这种选择器一旦组件模板微调就会挂维护成本很高。我收到 AI 生成的测试后第一件事就是把这种脆弱的嵌套选择器改成语义化的 class 选择器或者>