我一直有个观点大多数人对单元测试的抵触不是怕写代码而是怕“不知道测什么、不知道写到什么程度算够”。你让他给一个函数加断言他能写得挺好你让他给一个模块配好测试环境、解决依赖注入、处理异步竞态他就开始挠头了。这正是单元测试最微妙的地方——它看起来很小但一旦铺开涉及的东西一点都不少框架选型、目录约定、替身对象、覆盖率策略、CI接入哪一环都有讲究。这篇文章我尽量把“单元测试是什么、为什么值得写、怎么写才不白写”这条线一次性讲透。不堆术语不绕弯子直接从我实际在项目里落地的经验出发从零带你把一套可用的测试体系搭起来同时把那些写测试时最容易掉进去的坑一个个指出来。适合刚接触单元测试的同学也适合已经在写但总觉得“测试在拖后腿”的团队参考。1. 单元测试的边界感它到底在测什么不测什么很多人对单元测试的理解是从字面开始的——“对单元的测试”。但真正的难点在于你得先搞清楚什么是“单元”。1.1 “单元”不是一个固定大小的代码块而是“可独立验证的最小逻辑”我在代码评审时经常遇到一种情况有人把一个接口的完整调用链路测试写了一整串从数据库连到Redis再发MQ最后断言结果正确。这其实已经完全超出了单元测试的范畴属于集成测试。我个人的定义方式很简单单元是指一个不依赖外部真实资源就能独立运行的逻辑块。它通常是一个函数、一个类的方法、一个纯工具模块甚至一个Vue组件的某个行为。关键判据是——被测对象在跑起来的时候不需要真实的数据库连接、不需要真的发HTTP请求、不需要一个可用的消息队列。如果有这些依赖就要通过替身Stub/Mock来隔离。举个具体例子// 这是一个典型的“单元”纯函数无外部依赖 export function calcDiscount(price, coupon) { if (!coupon) return price; const rate coupon.type PERCENT ? coupon.value : 1; const maxDiscount coupon.maxDiscount || 0; const discounted coupon.type AMOUNT ? price - coupon.value : price * rate; return Math.max(0, Math.min(discounted, price - maxDiscount)); }这个函数没有依赖任何外部资源喂进去参数、吐出来结果逻辑完整这就是最理想的单元测试对象。1.2 单元测试、集成测试、端到端测试各自的“射程”把三种测试放在一起对比边界感会立刻清晰起来测试类型测试对象尺度对外部依赖的态度运行速度定位单元测试单个函数/方法/组件完全隔离使用替身毫秒级确认“零件合格”集成测试多个模块/服务间的协作使用真实的轻量依赖如测试库、真实HTTP调用秒级确认“零件之间咬合正确”端到端测试整个系统/用户关键路径全部真实分钟级确认“整台机器跑起来没问题”你会发现单元测试处在金字塔的最底层。它跑得最快、数量最多、定位最聚焦。它的价值不是证明“系统能用”而是证明“每一个零件自己没坏”。如果你想让一个测试替你做“点完登录按钮跳转到首页”这种验证那不是单元测试该干的事那是E2E测试的活儿。1.3 单元测试不管的事反而更重要我给团队定的规矩是凡是涉及真实外部资源的断言一律不许出现在单元测试里。具体包括不连数据库、不做真实查询不发起真实HTTP请求、不打真实支付接口不读真实文件系统、不开真实定时器不依赖真实系统时钟那这些依赖怎么测答案是注入替身。依赖注入不是为了“方便测试”才存在的它本身就是好设计的基本功。当你发现一个函数没法在不连数据库的情况测试时这通常不是测试的问题而是你的代码耦合度出了问题。所以我会说单元测试是一面镜子它照出的不只是逻辑正确性还照出了设计的健康度。2. 为什么单元测试值得写三个真实收益和一个必须接受的代价写测试是有成本的。如果你不认同它的收益后面的所有技巧都没意义因为你根本没有动力去用。我把它能带来的东西拆成三块每一块都是实操中能真切感受到的。2.1 回归保护改代码不怕了重构有底气这是单元测试最朴素也最硬核的收益。我做过一个营销活动配置系统活动规则里有阶梯折扣、满减、限购、会员优先多种条件组合判断逻辑非常绕。没有测试的时候每次产品提需求改规则我改完只能靠肉眼盯着控制台输出看结果对不对改A规则时把B规则带崩了也不自知。后来我花了一天时间把所有规则函数全部补上单元测试再改代码时只要跑一遍测试哪里被影响立刻见红。那种“有人帮你盯着”的感觉只有体会过才懂。2.2 设计反推写不出测试往往意味着代码结构有问题“可测试性”是最廉价的设计评审专家。当你尝试为一个模块写测试时你被迫思考这个函数依赖了哪些外部状态能不能通过参数传进来这个类是不是做了两件以上不相干的事这个模块的边界是清晰的还是一团浆糊一个经典的例子写一个Vue组件测试时发现组件内部直接localStorage.getItem(token)。为了完成单元测试你可能得在测试环境里专门mock整个localStorage。但你再想想为什么token读取不能封装成一个getToken()函数把读token这件事本身变成一个可依赖注入的单元组件测试变得干净代码的职责划分也更清楚了。2.3 活文档测试用例比注释更能说明“这代码该怎么用”优秀工程师写代码时会追求“自解释”但现实是业务代码的“为什么这么写”只有注释才能讲清楚而“怎么调用、有什么边界行为”恰恰是测试能完美表达的。我接手遗留项目时第一件事不是看README而是看测试文件。测试里写满了预期行为it(传0元购物车返回0不抛异常, () { expect(calcTotals([])).toEqual({ amount: 0, count: 0 }); });不需要文档不需要猜这就是代码最诚实的使用说明书。2.4 代价测试也是代码也有维护成本有人把单元测试说得像灵丹妙药但我不这么认为。你必须接受一个事实业务逻辑改变时测试也要跟着改。一次需求的正常迭代可能是“改一行业务代码 改三行测试断言”这个成本是真实存在的。还有表意成本如果断言写得混乱测试本身也会变成难以维护的负担。所以我的建议是务实地画一条线——核心业务规则、数据转换、状态管理、权限校验这类“改错了要出大事”的逻辑必须测一次性脚本、纯原型验证、视觉层布局这类“投入产出不划算”的代码可以先不测。你自己要有判断力不要被“100%覆盖率”的口号绑架这个后面专门讲。3. 一套能跑起来的测试体系从零选型到接入CI工具链的选择没有绝对标准但如果你在一个前端项目里问我“应该选哪个”我会毫不犹豫地说Jest。你可以在楼下看到它和其他主流框架的对比然后我带你把它跑起来。3.1 主流测试框架速览框架适用场景特点JestJavaScript/TypeScript全栈Vue/React生态零配置、内置断言库、快照、覆盖率、mock全家桶VitestVite项目、前端单测速度极快和Vite配置天然互通JUnitJava老牌生态成熟配合Mockito/Spock使用pytestPython简洁强大fixture机制非常好用xUnit系.NET微软官方体系集成度高VectorCAST汽车电子、航空航天等安全关键领域配合DO-178C等标准做MC/DC覆盖率需要许可证通常绑定交叉编译工具链和目标板3.2 以Jest为核心的搭建过程前端Vue项目为例如果你的项目是Vue 3 Vite我建议直接走Vitest配置更顺。这里为了覆盖更广的场景我用Jest Vue 3走一遍“能跑起来”的最小步骤。第一步安装依赖npm install --save-dev jest vue/test-utils vue/vue3-jest jest-environment-jsdomVue 3项目使用Jest时最容易被卡住的就是vue文件解析。Jest默认只能处理JS需要配置transform来转换SFC文件。示例配置如下// jest.config.js module.exports { testEnvironment: jsdom, transform: { ^.\\.vue$: vue/vue3-jest, ^.\\.[jt]sx?$: babel-jest }, moduleNameMapper: { \\.(css|less|scss)$: rootDir/__mocks__/styleMock.js }, coverageDirectory: rootDir/coverage };第二步写一个最简单的测试文件确认环境通了// src/utils/__tests__/price.spec.js import { calcDiscount } from ../price; describe(calcDiscount, () { it(无优惠券时返回原价, () { expect(calcDiscount(100, null)).toBe(100); }); it(按百分比折扣计算, () { expect(calcDiscount(100, { type: PERCENT, value: 0.8 })).toBe(80); }); });第三步在package.json里加脚本{ scripts: { test: jest, test:coverage: jest --coverage } }跑一下npm test。如果这一步绿灯你的测试体系就已经立起来了剩下的往里面填用例即可。3.3 接入CI测试不跑在流水线上等于白写本地写完测试不推送到CI就等于测试只对你一个人负责。我在团队里推行的是“MR合并前必须绿灯”策略在GitLab CI里加一个stage跑完单测后收集覆盖率并上传报告。命令大致长这样unit-test: stage: test script: - npm ci - npm run test:coverage artifacts: paths: - coverage/然后你就可以在流水线卡点上看到覆盖率趋势了。这里我多说一句CI的卡点不要一上来就卡“覆盖率不低于80%”。很多团队死在这条线上为了凑数字什么丑代码都写得出来。后面会细聊这个问题。3.4 安全关键领域的VectorCAST环境怎么搭如果你的行业是汽车电子、轨交或航空航天开源测试框架往往满足不了标准要求。这类项目会用到VectorCAST单纯软件层面要做的事情至少包括安装并激活许可证、配置宿主机的交叉编译器、给被测C/C代码做桩/打点、配置目标板通信链路、把测试用例与需求条目做追踪最后还要生成脚本化报告满足MC/DC覆盖率要求。这套环境和开源生态完全是另一套玩法它的价值重心不在“快”而在“可追溯、可审计”。如果你刚接触VectorCAST优先看官方安装手册里的“Compiler Configuration”部分大多数环境跑不起来的问题都出在这一步。4. 写一个测试用例的正确姿势三段式结构与断言技巧环境搭好只是开始怎么把测试用例写得规范、可读、可维护这才是真正拉开差距的地方。4.1 永远保持Arrange-Act-Assert三段式不管测什么我都建议你保持这个结构it(折扣后金额不为负数, () { // Arrange 准备 const price 50; const coupon { type: PERCENT, value: 0.2, maxDiscount: 100 }; // Act 执行 const result calcDiscount(price, coupon); // Assert 断言 expect(result).toBeGreaterThanOrEqual(0); });Arrange负责构造被测对象的上下文Act执行你要验证的动作Assert检查结果。这套结构在细节层面约束了每个用例的因果关系一个用例只测一件事。我看到过的反面案例是一个test里连续做了五六个断言失败了你根本不知道哪一步出了问题。那种用例的价值大打折扣。4.2 断言技巧这些坑比你想的更常见断言写不对测试就是自欺欺人。以下几个细节你需要特别留意对象断言用toEqual不用toBe。toBe比较的是引用两个内容相同的对象也会失败折磨新手最狠的就是这个。// 会挂两个对象引用不同 expect(compute()).toBe({ total: 10 }); // 正确 expect(compute()).toEqual({ total: 10 });浮点数用toBeCloseTo不要用toEqual。JS浮点运算的经典玄学0.1 0.2 ! 0.3不会消失toBeCloseTo(0.3, 5)才是正确的打开方式。异常用例要用toThrow并且尽量断言错误信息不要只断“抛了异常”。如果一个函数因为参数不对抛错了光验证“抛错”不够你还得验证是“哪一种错”否则两个不同的bug可能互相掩盖。it(折扣比例非法时抛错, () { expect(() calcDiscount(100, { type: PERCENT, value: 1.5 })) .toThrow(折扣比例不能大于1); });4.3 命名与描述测试是给未来的自己读的测试文件的命名和用例描述建议直接参考“行为驱动”的写法it(should return original price when no coupon is provided)。中文团队可以写完整中文但描述要包含输入条件和预期行为两部分。比如好it(用户没有优惠券时返回原始价格)一般it(测试calcDiscount函数)差it(test 1)这是最廉价的文档投资。三个月后你自己回头看能一眼知道这个用例在保护什么行为这比任何注释都靠谱。5. 测试替身Test Doublemock、stub、fake怎么用才不惹祸单元测试最大的“难”不是写断言而是处理依赖。这里引入一个核心概念测试替身。很多人一提到替身就都叫Mock其实细分下来是有区别的。5.1 概念辨析Mock不是你想的那个东西替身类型用途简单理解Stub给被测对象提供固定输入替身自身不带断言一个“只会演戏的假道具”Mock验证与被替对象之间的交互是否发生带断言一个“会记仇的假演员”盯着你有没有按剧本打电话Fake轻量级真实实现例如用内存数组实现仓库接口一个“真的能用但不联网的假数据库”Spy包裹真实对象记录其调用情况一个“装了监控的真演员”举个例子如果要测一个订单服务是否在库存不足时调用告警接口你其实应该用Mock来验证“告警方法被调用了”这个交互而如果要测一个查询方法在传特定参数时返回什么结果用Stub就好。5.2 Mock的滥用测试不再是行为的守护者而是实现的复读机这是我在代码评审中看到频率最高的问题。很多初级写测试的人喜欢把一切依赖全部mock掉结果就是测试里堆满了对内部调用路径的断言// 反面案例Mock了内部函数的每一步调用 it(提交订单成功, () { const saveSpy vi.spyOn(orderRepo, save); const notifySpy vi.spyOn(notify, send); await submitOrder(orderData); expect(saveSpy).toHaveBeenCalledTimes(1); expect(notifySpy).toHaveBeenCalledWith(order_created, expect.any(Object)); });问题在哪这些断言本质上是在复述代码实现而不是验证行为正确性。哪天你重构了内部逻辑把save和notify合并成一个事务方法测试会立刻变红但业务行为根本没变。这种测试非但不保护你反而成为重构的猪队友。我的原则是对外部不可控依赖网络、时间、随机数做替身对内部模块的协作尽量用真实实现。让测试去验证“输入输出对不对”而不是“内部是不是按某条路径走”。5.3 什么时候千万不要Mock有一种情况我明确建议你不要用替身——被测对象本身就是纯函数。既然它无副作用、无依赖为什么还要引入替身直接在真实实现上断言就好了。我看到过有人给一个纯工具函数里的Math.random做mock只为了断言“随机数固定时输出固定”。这完全是画蛇添足。如果业务需要可复现的随机行为应该设计成randomFn参数注入而不是测试时去拦截全局对象。5.4 Vue组件测试里的替身实践结合“vue单元测试”的场景提一句。测试一个Vue组件时最常见的替身需求是两类一类是子组件的替身一类是API模块的替身。对于API调用的隔离我推荐把请求封装成单独的模块然后在测试里mock这个模块而不是mock整个axios实例。// 组件代码 import { fetchUser } from /api/user; // 测试中 vi.mock(/api/user, () ({ fetchUser: vi.fn(() Promise.resolve({ name: Alice })) }));这样测试只关心“组件在拿到用户数据后的渲染行为”而不是关心请求库本身。又干净又不容易被底层库变更波及。6. 我在Vue项目里踩过的单元测试报错三个高频坑排查实录从热搜词里看到“vue单元测试报错”出现频率不低说明这块确实是新手重灾区。我把这几年带团队时被问得最多的三个报错场景整理出来每个都给排查思路而不是直接甩答案。6.1 报错一Jest无法识别.vue文件报SyntaxError这个报错的典型特征是Cannot parse file, expected syntax几乎每个刚配Jest的Vue项目都会撞上。原因就是你在jest.config.js里没有配置vue-jest的transform。排查顺序我建议是确认配置文件里transform是否包含^.\\.vue$确认对应transform包名和Vue版本是否匹配——Vue 2用vue-jestVue 3用vue/vue3-jest确认安装的是babel-jest还是swc等替代品如果组件里用了TypeScript还要配置对应的ts处理这类问题九成是配置问题环境本身没病。6.2 报错二测试里引用了CSS/图片资源运行直接失败这种报错在Vue项目里特别常见Cannot find module /styles/common.less组件里import /styles/common.less但Jest不认识非JS资源。解决办法是在moduleNameMapper里做映射把样式文件映射为空模块moduleNameMapper: { \\.(css|less|scss|sass)$: rootDir/test/styleMock.js }styleMock.js只需一行module.exports {};。同理图片资源也可以映射成一张透明的占位图或者直接映射为一个空字符串。6.3 报错三异步组件或定时器的测试不稳定时红时绿这是比配置坑更难排查的一类。典型场景测试一个带setTimeout的组件或者测一个发请求后更新状态的组件。第一次跑通过了第二次跑就挂你以为是测试代码有问题其实是没有控制好执行时机。处理定时器Jest提供了fake timersjest.useFakeTimers(); it(延迟3秒后触发回调, () { const callback jest.fn(); debounce(callback, 3000); jest.advanceTimersByTime(3000); expect(callback).toHaveBeenCalled(); });处理异步请求用async/await配合flush-promises是一个稳妥的组合await flushPromises(); expect(wrapper.text()).toContain(加载完成);核心思路是不要依赖真实的等待时间测试必须是确定性的。如果你写的测试因为“慢了100毫秒”而失败那不是业务代码的错是测试本身没设计好。6.4 排查报错的一个通用思路最后分享一个通用的排查经验在看到报错信息时不要一上来就搜全网答案。先看报错的第一行——是“语法解析失败”还是“断言失败”这决定了问题的层次。配置类问题通常和“could not find module”“cannot parse”连在一起逻辑类问题通常和“expected... received...”连在一起。把层次定位清楚再动手排查效率和成功率都高得多。7. 别被覆盖率绑架如何判断一个测试是真的有用还是自欺欺人再继续谈一个关于覆盖率的话题。很多团队做单元测试最后都会卡在“覆盖率指标”上。我见过的最夸张的项目覆盖率97%但核心支付逻辑一条测试都没有——因为开发把大量暗示性测试堆在了工具函数和DTO上面凑足了行覆盖。7.1 行覆盖率不是信心的同义词行覆盖率只能告诉你“哪些代码被执行了”不能告诉你“这些代码的行为是否被验证了”。一个典型的案例if (discount 1) throw new Error(discount invalid); return price;如果测试只跑了price正常返回的分支没有覆盖discount 1的异常分支行覆盖率可能是50%但你没有验证最关键的保护逻辑。所以我对团队的要求是与其盯行覆盖率数字不如盯“每个关键分支都有对应用例”这个更本质的约定。7.2 自测方法做一次“变异测试”不需要任何工具你可以在code review的时候做个简单的实验——把被测代码里的临时改成或把返回值加1然后看测试会不会变红。如果测试全绿说明你的用例根本没有在验证这个行为。这就是大家常说的“变异测试”思想不一定非要上工具人工做几次就能发现一堆名义测试。7.3 有效测试的判断标准我在团队里用三个问题来判断一个测试是否为有效测试如果这个断言失败我能明确知道“哪里坏了”吗——答不出来说明断言不够聚焦。如果把被测逻辑删掉测试能发现吗——答不出说明这是无效测试。这个测试是否描述了用户可见或业务明确的行为——答不出说明是内部实现的复读机。用这三个问题过滤测试比你定“覆盖率不低于80%”的指标有用十倍。7.4 什么样的代码值得优先测排一个优先级供你对照自己的项目第一优先级核心业务规则价格计算、优惠叠加、库存算法、权限矩阵第二优先级数据转换与边界处理API响应格式化、状态机流转、时间区间计算第三优先级基础设施的缺陷回归曾经出过线上bug的代码不优先UI像素级布局、模板渲染细节、一次性脚本你会发现这个优先级不是按代码量排的而是按出错代价排的。单元测试本质上是一种风险对冲——把资源放在损失最大的地方收益最高。最后关于单元测试我实际操作中的一点体会单元测试这件事一开始你会觉得“多写了一堆代码”跑起来之后你会觉得“像是雇了一个质检员”时间长了你会发现它其实是在改造你的代码习惯。写之前你不在意依赖、不在意副作用、不区分纯函数和过程代码写完之后你会下意识地把可测试性当作设计目标。就凭这一点我觉得它值得每个项目至少尝试一次。我的建议很直接不必追求全量覆盖挑一块核心业务逻辑从本周开始配上测试跑一个月看看自己的变化。
我一直有个观点大多数人对单元测试的抵触不是怕写代码而是怕“不知道测什么、不知道写到什么程度算够”。你让他给一个函数加断言他能写得挺好你让他给一个模块配好测试环境、解决依赖注入、处理异步竞态他就开始挠头了。这正是单元测试最微妙的地方——它看起来很小但一旦铺开涉及的东西一点都不少框架选型、目录约定、替身对象、覆盖率策略、CI接入哪一环都有讲究。这篇文章我尽量把“单元测试是什么、为什么值得写、怎么写才不白写”这条线一次性讲透。不堆术语不绕弯子直接从我实际在项目里落地的经验出发从零带你把一套可用的测试体系搭起来同时把那些写测试时最容易掉进去的坑一个个指出来。适合刚接触单元测试的同学也适合已经在写但总觉得“测试在拖后腿”的团队参考。1. 单元测试的边界感它到底在测什么不测什么很多人对单元测试的理解是从字面开始的——“对单元的测试”。但真正的难点在于你得先搞清楚什么是“单元”。1.1 “单元”不是一个固定大小的代码块而是“可独立验证的最小逻辑”我在代码评审时经常遇到一种情况有人把一个接口的完整调用链路测试写了一整串从数据库连到Redis再发MQ最后断言结果正确。这其实已经完全超出了单元测试的范畴属于集成测试。我个人的定义方式很简单单元是指一个不依赖外部真实资源就能独立运行的逻辑块。它通常是一个函数、一个类的方法、一个纯工具模块甚至一个Vue组件的某个行为。关键判据是——被测对象在跑起来的时候不需要真实的数据库连接、不需要真的发HTTP请求、不需要一个可用的消息队列。如果有这些依赖就要通过替身Stub/Mock来隔离。举个具体例子// 这是一个典型的“单元”纯函数无外部依赖 export function calcDiscount(price, coupon) { if (!coupon) return price; const rate coupon.type PERCENT ? coupon.value : 1; const maxDiscount coupon.maxDiscount || 0; const discounted coupon.type AMOUNT ? price - coupon.value : price * rate; return Math.max(0, Math.min(discounted, price - maxDiscount)); }这个函数没有依赖任何外部资源喂进去参数、吐出来结果逻辑完整这就是最理想的单元测试对象。1.2 单元测试、集成测试、端到端测试各自的“射程”把三种测试放在一起对比边界感会立刻清晰起来测试类型测试对象尺度对外部依赖的态度运行速度定位单元测试单个函数/方法/组件完全隔离使用替身毫秒级确认“零件合格”集成测试多个模块/服务间的协作使用真实的轻量依赖如测试库、真实HTTP调用秒级确认“零件之间咬合正确”端到端测试整个系统/用户关键路径全部真实分钟级确认“整台机器跑起来没问题”你会发现单元测试处在金字塔的最底层。它跑得最快、数量最多、定位最聚焦。它的价值不是证明“系统能用”而是证明“每一个零件自己没坏”。如果你想让一个测试替你做“点完登录按钮跳转到首页”这种验证那不是单元测试该干的事那是E2E测试的活儿。1.3 单元测试不管的事反而更重要我给团队定的规矩是凡是涉及真实外部资源的断言一律不许出现在单元测试里。具体包括不连数据库、不做真实查询不发起真实HTTP请求、不打真实支付接口不读真实文件系统、不开真实定时器不依赖真实系统时钟那这些依赖怎么测答案是注入替身。依赖注入不是为了“方便测试”才存在的它本身就是好设计的基本功。当你发现一个函数没法在不连数据库的情况测试时这通常不是测试的问题而是你的代码耦合度出了问题。所以我会说单元测试是一面镜子它照出的不只是逻辑正确性还照出了设计的健康度。2. 为什么单元测试值得写三个真实收益和一个必须接受的代价写测试是有成本的。如果你不认同它的收益后面的所有技巧都没意义因为你根本没有动力去用。我把它能带来的东西拆成三块每一块都是实操中能真切感受到的。2.1 回归保护改代码不怕了重构有底气这是单元测试最朴素也最硬核的收益。我做过一个营销活动配置系统活动规则里有阶梯折扣、满减、限购、会员优先多种条件组合判断逻辑非常绕。没有测试的时候每次产品提需求改规则我改完只能靠肉眼盯着控制台输出看结果对不对改A规则时把B规则带崩了也不自知。后来我花了一天时间把所有规则函数全部补上单元测试再改代码时只要跑一遍测试哪里被影响立刻见红。那种“有人帮你盯着”的感觉只有体会过才懂。2.2 设计反推写不出测试往往意味着代码结构有问题“可测试性”是最廉价的设计评审专家。当你尝试为一个模块写测试时你被迫思考这个函数依赖了哪些外部状态能不能通过参数传进来这个类是不是做了两件以上不相干的事这个模块的边界是清晰的还是一团浆糊一个经典的例子写一个Vue组件测试时发现组件内部直接localStorage.getItem(token)。为了完成单元测试你可能得在测试环境里专门mock整个localStorage。但你再想想为什么token读取不能封装成一个getToken()函数把读token这件事本身变成一个可依赖注入的单元组件测试变得干净代码的职责划分也更清楚了。2.3 活文档测试用例比注释更能说明“这代码该怎么用”优秀工程师写代码时会追求“自解释”但现实是业务代码的“为什么这么写”只有注释才能讲清楚而“怎么调用、有什么边界行为”恰恰是测试能完美表达的。我接手遗留项目时第一件事不是看README而是看测试文件。测试里写满了预期行为it(传0元购物车返回0不抛异常, () { expect(calcTotals([])).toEqual({ amount: 0, count: 0 }); });不需要文档不需要猜这就是代码最诚实的使用说明书。2.4 代价测试也是代码也有维护成本有人把单元测试说得像灵丹妙药但我不这么认为。你必须接受一个事实业务逻辑改变时测试也要跟着改。一次需求的正常迭代可能是“改一行业务代码 改三行测试断言”这个成本是真实存在的。还有表意成本如果断言写得混乱测试本身也会变成难以维护的负担。所以我的建议是务实地画一条线——核心业务规则、数据转换、状态管理、权限校验这类“改错了要出大事”的逻辑必须测一次性脚本、纯原型验证、视觉层布局这类“投入产出不划算”的代码可以先不测。你自己要有判断力不要被“100%覆盖率”的口号绑架这个后面专门讲。3. 一套能跑起来的测试体系从零选型到接入CI工具链的选择没有绝对标准但如果你在一个前端项目里问我“应该选哪个”我会毫不犹豫地说Jest。你可以在楼下看到它和其他主流框架的对比然后我带你把它跑起来。3.1 主流测试框架速览框架适用场景特点JestJavaScript/TypeScript全栈Vue/React生态零配置、内置断言库、快照、覆盖率、mock全家桶VitestVite项目、前端单测速度极快和Vite配置天然互通JUnitJava老牌生态成熟配合Mockito/Spock使用pytestPython简洁强大fixture机制非常好用xUnit系.NET微软官方体系集成度高VectorCAST汽车电子、航空航天等安全关键领域配合DO-178C等标准做MC/DC覆盖率需要许可证通常绑定交叉编译工具链和目标板3.2 以Jest为核心的搭建过程前端Vue项目为例如果你的项目是Vue 3 Vite我建议直接走Vitest配置更顺。这里为了覆盖更广的场景我用Jest Vue 3走一遍“能跑起来”的最小步骤。第一步安装依赖npm install --save-dev jest vue/test-utils vue/vue3-jest jest-environment-jsdomVue 3项目使用Jest时最容易被卡住的就是vue文件解析。Jest默认只能处理JS需要配置transform来转换SFC文件。示例配置如下// jest.config.js module.exports { testEnvironment: jsdom, transform: { ^.\\.vue$: vue/vue3-jest, ^.\\.[jt]sx?$: babel-jest }, moduleNameMapper: { \\.(css|less|scss)$: rootDir/__mocks__/styleMock.js }, coverageDirectory: rootDir/coverage };第二步写一个最简单的测试文件确认环境通了// src/utils/__tests__/price.spec.js import { calcDiscount } from ../price; describe(calcDiscount, () { it(无优惠券时返回原价, () { expect(calcDiscount(100, null)).toBe(100); }); it(按百分比折扣计算, () { expect(calcDiscount(100, { type: PERCENT, value: 0.8 })).toBe(80); }); });第三步在package.json里加脚本{ scripts: { test: jest, test:coverage: jest --coverage } }跑一下npm test。如果这一步绿灯你的测试体系就已经立起来了剩下的往里面填用例即可。3.3 接入CI测试不跑在流水线上等于白写本地写完测试不推送到CI就等于测试只对你一个人负责。我在团队里推行的是“MR合并前必须绿灯”策略在GitLab CI里加一个stage跑完单测后收集覆盖率并上传报告。命令大致长这样unit-test: stage: test script: - npm ci - npm run test:coverage artifacts: paths: - coverage/然后你就可以在流水线卡点上看到覆盖率趋势了。这里我多说一句CI的卡点不要一上来就卡“覆盖率不低于80%”。很多团队死在这条线上为了凑数字什么丑代码都写得出来。后面会细聊这个问题。3.4 安全关键领域的VectorCAST环境怎么搭如果你的行业是汽车电子、轨交或航空航天开源测试框架往往满足不了标准要求。这类项目会用到VectorCAST单纯软件层面要做的事情至少包括安装并激活许可证、配置宿主机的交叉编译器、给被测C/C代码做桩/打点、配置目标板通信链路、把测试用例与需求条目做追踪最后还要生成脚本化报告满足MC/DC覆盖率要求。这套环境和开源生态完全是另一套玩法它的价值重心不在“快”而在“可追溯、可审计”。如果你刚接触VectorCAST优先看官方安装手册里的“Compiler Configuration”部分大多数环境跑不起来的问题都出在这一步。4. 写一个测试用例的正确姿势三段式结构与断言技巧环境搭好只是开始怎么把测试用例写得规范、可读、可维护这才是真正拉开差距的地方。4.1 永远保持Arrange-Act-Assert三段式不管测什么我都建议你保持这个结构it(折扣后金额不为负数, () { // Arrange 准备 const price 50; const coupon { type: PERCENT, value: 0.2, maxDiscount: 100 }; // Act 执行 const result calcDiscount(price, coupon); // Assert 断言 expect(result).toBeGreaterThanOrEqual(0); });Arrange负责构造被测对象的上下文Act执行你要验证的动作Assert检查结果。这套结构在细节层面约束了每个用例的因果关系一个用例只测一件事。我看到过的反面案例是一个test里连续做了五六个断言失败了你根本不知道哪一步出了问题。那种用例的价值大打折扣。4.2 断言技巧这些坑比你想的更常见断言写不对测试就是自欺欺人。以下几个细节你需要特别留意对象断言用toEqual不用toBe。toBe比较的是引用两个内容相同的对象也会失败折磨新手最狠的就是这个。// 会挂两个对象引用不同 expect(compute()).toBe({ total: 10 }); // 正确 expect(compute()).toEqual({ total: 10 });浮点数用toBeCloseTo不要用toEqual。JS浮点运算的经典玄学0.1 0.2 ! 0.3不会消失toBeCloseTo(0.3, 5)才是正确的打开方式。异常用例要用toThrow并且尽量断言错误信息不要只断“抛了异常”。如果一个函数因为参数不对抛错了光验证“抛错”不够你还得验证是“哪一种错”否则两个不同的bug可能互相掩盖。it(折扣比例非法时抛错, () { expect(() calcDiscount(100, { type: PERCENT, value: 1.5 })) .toThrow(折扣比例不能大于1); });4.3 命名与描述测试是给未来的自己读的测试文件的命名和用例描述建议直接参考“行为驱动”的写法it(should return original price when no coupon is provided)。中文团队可以写完整中文但描述要包含输入条件和预期行为两部分。比如好it(用户没有优惠券时返回原始价格)一般it(测试calcDiscount函数)差it(test 1)这是最廉价的文档投资。三个月后你自己回头看能一眼知道这个用例在保护什么行为这比任何注释都靠谱。5. 测试替身Test Doublemock、stub、fake怎么用才不惹祸单元测试最大的“难”不是写断言而是处理依赖。这里引入一个核心概念测试替身。很多人一提到替身就都叫Mock其实细分下来是有区别的。5.1 概念辨析Mock不是你想的那个东西替身类型用途简单理解Stub给被测对象提供固定输入替身自身不带断言一个“只会演戏的假道具”Mock验证与被替对象之间的交互是否发生带断言一个“会记仇的假演员”盯着你有没有按剧本打电话Fake轻量级真实实现例如用内存数组实现仓库接口一个“真的能用但不联网的假数据库”Spy包裹真实对象记录其调用情况一个“装了监控的真演员”举个例子如果要测一个订单服务是否在库存不足时调用告警接口你其实应该用Mock来验证“告警方法被调用了”这个交互而如果要测一个查询方法在传特定参数时返回什么结果用Stub就好。5.2 Mock的滥用测试不再是行为的守护者而是实现的复读机这是我在代码评审中看到频率最高的问题。很多初级写测试的人喜欢把一切依赖全部mock掉结果就是测试里堆满了对内部调用路径的断言// 反面案例Mock了内部函数的每一步调用 it(提交订单成功, () { const saveSpy vi.spyOn(orderRepo, save); const notifySpy vi.spyOn(notify, send); await submitOrder(orderData); expect(saveSpy).toHaveBeenCalledTimes(1); expect(notifySpy).toHaveBeenCalledWith(order_created, expect.any(Object)); });问题在哪这些断言本质上是在复述代码实现而不是验证行为正确性。哪天你重构了内部逻辑把save和notify合并成一个事务方法测试会立刻变红但业务行为根本没变。这种测试非但不保护你反而成为重构的猪队友。我的原则是对外部不可控依赖网络、时间、随机数做替身对内部模块的协作尽量用真实实现。让测试去验证“输入输出对不对”而不是“内部是不是按某条路径走”。5.3 什么时候千万不要Mock有一种情况我明确建议你不要用替身——被测对象本身就是纯函数。既然它无副作用、无依赖为什么还要引入替身直接在真实实现上断言就好了。我看到过有人给一个纯工具函数里的Math.random做mock只为了断言“随机数固定时输出固定”。这完全是画蛇添足。如果业务需要可复现的随机行为应该设计成randomFn参数注入而不是测试时去拦截全局对象。5.4 Vue组件测试里的替身实践结合“vue单元测试”的场景提一句。测试一个Vue组件时最常见的替身需求是两类一类是子组件的替身一类是API模块的替身。对于API调用的隔离我推荐把请求封装成单独的模块然后在测试里mock这个模块而不是mock整个axios实例。// 组件代码 import { fetchUser } from /api/user; // 测试中 vi.mock(/api/user, () ({ fetchUser: vi.fn(() Promise.resolve({ name: Alice })) }));这样测试只关心“组件在拿到用户数据后的渲染行为”而不是关心请求库本身。又干净又不容易被底层库变更波及。6. 我在Vue项目里踩过的单元测试报错三个高频坑排查实录从热搜词里看到“vue单元测试报错”出现频率不低说明这块确实是新手重灾区。我把这几年带团队时被问得最多的三个报错场景整理出来每个都给排查思路而不是直接甩答案。6.1 报错一Jest无法识别.vue文件报SyntaxError这个报错的典型特征是Cannot parse file, expected syntax几乎每个刚配Jest的Vue项目都会撞上。原因就是你在jest.config.js里没有配置vue-jest的transform。排查顺序我建议是确认配置文件里transform是否包含^.\\.vue$确认对应transform包名和Vue版本是否匹配——Vue 2用vue-jestVue 3用vue/vue3-jest确认安装的是babel-jest还是swc等替代品如果组件里用了TypeScript还要配置对应的ts处理这类问题九成是配置问题环境本身没病。6.2 报错二测试里引用了CSS/图片资源运行直接失败这种报错在Vue项目里特别常见Cannot find module /styles/common.less组件里import /styles/common.less但Jest不认识非JS资源。解决办法是在moduleNameMapper里做映射把样式文件映射为空模块moduleNameMapper: { \\.(css|less|scss|sass)$: rootDir/test/styleMock.js }styleMock.js只需一行module.exports {};。同理图片资源也可以映射成一张透明的占位图或者直接映射为一个空字符串。6.3 报错三异步组件或定时器的测试不稳定时红时绿这是比配置坑更难排查的一类。典型场景测试一个带setTimeout的组件或者测一个发请求后更新状态的组件。第一次跑通过了第二次跑就挂你以为是测试代码有问题其实是没有控制好执行时机。处理定时器Jest提供了fake timersjest.useFakeTimers(); it(延迟3秒后触发回调, () { const callback jest.fn(); debounce(callback, 3000); jest.advanceTimersByTime(3000); expect(callback).toHaveBeenCalled(); });处理异步请求用async/await配合flush-promises是一个稳妥的组合await flushPromises(); expect(wrapper.text()).toContain(加载完成);核心思路是不要依赖真实的等待时间测试必须是确定性的。如果你写的测试因为“慢了100毫秒”而失败那不是业务代码的错是测试本身没设计好。6.4 排查报错的一个通用思路最后分享一个通用的排查经验在看到报错信息时不要一上来就搜全网答案。先看报错的第一行——是“语法解析失败”还是“断言失败”这决定了问题的层次。配置类问题通常和“could not find module”“cannot parse”连在一起逻辑类问题通常和“expected... received...”连在一起。把层次定位清楚再动手排查效率和成功率都高得多。7. 别被覆盖率绑架如何判断一个测试是真的有用还是自欺欺人再继续谈一个关于覆盖率的话题。很多团队做单元测试最后都会卡在“覆盖率指标”上。我见过的最夸张的项目覆盖率97%但核心支付逻辑一条测试都没有——因为开发把大量暗示性测试堆在了工具函数和DTO上面凑足了行覆盖。7.1 行覆盖率不是信心的同义词行覆盖率只能告诉你“哪些代码被执行了”不能告诉你“这些代码的行为是否被验证了”。一个典型的案例if (discount 1) throw new Error(discount invalid); return price;如果测试只跑了price正常返回的分支没有覆盖discount 1的异常分支行覆盖率可能是50%但你没有验证最关键的保护逻辑。所以我对团队的要求是与其盯行覆盖率数字不如盯“每个关键分支都有对应用例”这个更本质的约定。7.2 自测方法做一次“变异测试”不需要任何工具你可以在code review的时候做个简单的实验——把被测代码里的临时改成或把返回值加1然后看测试会不会变红。如果测试全绿说明你的用例根本没有在验证这个行为。这就是大家常说的“变异测试”思想不一定非要上工具人工做几次就能发现一堆名义测试。7.3 有效测试的判断标准我在团队里用三个问题来判断一个测试是否为有效测试如果这个断言失败我能明确知道“哪里坏了”吗——答不出来说明断言不够聚焦。如果把被测逻辑删掉测试能发现吗——答不出说明这是无效测试。这个测试是否描述了用户可见或业务明确的行为——答不出说明是内部实现的复读机。用这三个问题过滤测试比你定“覆盖率不低于80%”的指标有用十倍。7.4 什么样的代码值得优先测排一个优先级供你对照自己的项目第一优先级核心业务规则价格计算、优惠叠加、库存算法、权限矩阵第二优先级数据转换与边界处理API响应格式化、状态机流转、时间区间计算第三优先级基础设施的缺陷回归曾经出过线上bug的代码不优先UI像素级布局、模板渲染细节、一次性脚本你会发现这个优先级不是按代码量排的而是按出错代价排的。单元测试本质上是一种风险对冲——把资源放在损失最大的地方收益最高。最后关于单元测试我实际操作中的一点体会单元测试这件事一开始你会觉得“多写了一堆代码”跑起来之后你会觉得“像是雇了一个质检员”时间长了你会发现它其实是在改造你的代码习惯。写之前你不在意依赖、不在意副作用、不区分纯函数和过程代码写完之后你会下意识地把可测试性当作设计目标。就凭这一点我觉得它值得每个项目至少尝试一次。我的建议很直接不必追求全量覆盖挑一块核心业务逻辑从本周开始配上测试跑一个月看看自己的变化。
