前端测试体系

四、异步与网络

不要真的发请求。两种主流做法：

// 1. mock 模块（适合简单场景）
vi.mock("./api", () => ({
  fetchUser: vi.fn().mockResolvedValue({ id: "1", name: "张三" }),
}));

// 2. MSW：在网络层拦截，组件代码零改动，最推荐
import { http, HttpResponse } from "msw";
import { setupServer } from "msw/node";

const server = setupServer(
  http.get("/api/user/:id", ({ params }) =>
    HttpResponse.json({ id: params.id, name: "张三" })
  )
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

MSW 的好处：测试代码里不出现任何 mock 语法，组件照常用 fetch，将来换成真实后端也不用改测试。

五、E2E（Playwright）

import { test, expect } from "@playwright/test";

test("用户可以完成登录并看到工作台", async ({ page }) => {
  await page.goto("/login");
  await page.getByLabel("邮箱").fill("test@example.com");
  await page.getByLabel("密码").fill("123456");
  await page.getByRole("button", { name: "登录" }).click();

  await expect(page).toHaveURL("/dashboard");
  await expect(page.getByRole("heading", { name: "工作台" })).toBeVisible();
});

稳定性要点（flaky 是 E2E 最大的敌人）：

• 用 expect(...).toBeVisible() 自动等待，不要写 waitForTimeout
• 每个用例独立准备数据，不依赖执行顺序
• 只覆盖"登录、下单、支付"这类断了就是事故的链路

Playwright 相比 Cypress 更适合跨浏览器与并行，Cypress 的调试体验更好。新项目默认选 Playwright。

六、覆盖率：看趋势，不看数字

覆盖率高不等于测得对——只断言"没抛错"也能刷到 100%。实践中：

• 别设硬性门槛（如 80% 必须达标），会催生无意义的断言
• 重点看新增代码的覆盖率（diff coverage）
• 覆盖率下降时问一句"是删了测试，还是这部分确实不用测"

七、接进 CI

# .github/workflows/test.yml 片段
- run: npm ci
- run: npm run typecheck      # tsc --noEmit
- run: npm run lint
- run: npm run test -- --coverage
- run: npx playwright test

顺序有讲究：先跑最快的、最容易失败的。类型检查 10 秒，E2E 10 分钟，不要反过来。

八、常见追问

• 单测和集成测试的边界在哪？（是否跨越了模块/网络的真实边界）
• 为什么说"测试实现细节"是反模式？
• TDD 适合什么场景？（逻辑清晰、可预期 → 适合；UI 探索阶段 → 不适合）
• 如何测试一个含 setTimeout 的逻辑？（vi.useFakeTimers() + vi.advanceTimersByTime()）

参考

• Vitest 文档
• Testing Library 查询优先级
• Playwright 文档