web前端测试

去年我接手了一个后台管理系统，端测需求方说“很简单，端测就是端测几个表格和表单”。结果改到第三周，端测一个日期格式的端测边界条件把整个提交按钮搞崩了——用户选2月30号，后端直接500。端测那天晚上我对着控制台骂了自己十分钟。端测如果当时有一个针对日期组件的端测边界测试，这事儿根本不会发生。端测

前端测试不是端测“锦上添花”，它是端测你半夜不被叫起来改bug的保险。但很多人一听到“测试”就想到写一堆expect(...).toBe(...)，端测然后跑一遍覆盖率，端测觉得完事了。端测实际上，前端测试的坑比写业务代码还多。

三种测试，别搞混

单元测试测的是函数、工具方法、纯逻辑。比如你写了一个formatPrice(12.345)，期望返回"12.35"，那就写个用例。这种测试跑得快，写起来也简单，Jest 或 Vitest 几行搞定。但别指望它发现UI上的问题——单元测试里没有DOM，没有样式，没有用户点击。

组件测试才是前端真正的战场。用 Testing Library 渲染一个<DatePicker />，模拟用户点开面板、切换月份、点击某一天，然后断言输入框的值。这能抓住大部分交互bug。我见过有人用 Enzyme 的shallow渲染，结果测了个寂寞——子组件根本没渲染，事件也没绑上。现在主流是 React Testing Library 或 Vue Test Utils，原则就一条：像用户一样去测，别去碰组件内部状态。

端到端测试（E2E）用 Cypress 或 Playwright，开个真浏览器，从登录一路点到下单。慢，但值。我们有个项目上了 Cypress 之后，每次发版前跑一遍，至少能拦住三四个“我本地是好的”那种问题。不过 E2E 别写太多，维护成本高，挑核心流程就行——登录、支付、关键表单提交。

一个真实的翻车案例

之前有个搜索框组件，输入关键词后防抖300毫秒再发请求。单元测试测了防抖函数本身，没问题。组件测试里，我们用jest.useFakeTimers()快进时间，也通过了。上线后用户反馈：快速输入“abc”，有时候会先发“ab”的请求，再发“abc”的，但“ab”的结果后回来，把“abc”的列表覆盖了。

问题出在竞态条件。测试里我们只模拟了单次输入，没有模拟连续快速输入。后来加了一个测试：连续触发三次输入，手动控制每个请求的返回顺序，断言最终显示的必须是最后一次请求的结果。这个测试写起来有点绕，但从此再没出过类似问题。

// 伪代码示意 test('快速输入时，只显示最后一次请求的结果', async () => {  const user = userEvent.setup(); render(<Search />); const input = screen.getByRole('textbox'); await user.type(input, 'a'); await user.type(input, 'b'); // 此时第一个请求还没返回 await user.type(input, 'c'); // 手动让第一个请求晚于第三个返回 mockRequest.mockResolvedValueOnce(delay(300, ['a结果'])); mockRequest.mockResolvedValueOnce(delay(100, ['ab结果'])); mockRequest.mockResolvedValueOnce(delay(50, ['abc结果'])); await waitFor(() => {  expect(screen.getByText('abc结果')).toBeInTheDocument(); }); expect(screen.queryByText('a结果')).not.toBeInTheDocument(); }); 

你看，这种测试才是真正值钱的。它模拟了真实世界的混乱，而不是理想化的顺序执行。

别被覆盖率骗了

我现在的习惯：新项目上来先配好 Vitest + Testing Library，写业务代码时顺手把核心逻辑的测试补上。覆盖率报告我只看两个数——分支覆盖率和函数覆盖率。行覆盖率90%但分支覆盖率40%的项目，大概率藏着一堆if/else没测到的坑。

还有，别追求100%。有些代码就是胶水，比如export default connect(mapState)(Component)，测它纯属浪费时间。把精力花在：工具函数、复杂条件渲染、用户交互路径、错误处理分支。这些地方出了bug，用户直接骂娘。

“测试写得好，下班回家早。”——我前同事的名言，他每天六点准时走，线上事故率全组最低。

最后说个实在的：如果你现在项目里一行测试都没有，别想着一步到位。从下一个bug开始——修完bug后，写一个能复现它的测试。下次再有人改这块代码，测试会替你盯着。这比任何测试规范都管用。