vault backup: 2026-04-29 23:36:32
This commit is contained in:
+187
-5
@@ -146,11 +146,84 @@ describe("<UserCard />", () => {
|
||||
});
|
||||
```
|
||||
|
||||
### 快照测试
|
||||
|
||||
> [!tip] Snapshot 的定位
|
||||
> 快照不是单元测试的替代品——它检测的是**UI 结构意外变化**。
|
||||
> 适用于不会频繁变化的展示型组件（如仪表盘卡片、文章详情页）。
|
||||
> 不适用于动态数据多的列表或表单。
|
||||
|
||||
```tsx
|
||||
import { render } from "@testing-library/react";
|
||||
import { UserDetail } from "./UserDetail";
|
||||
|
||||
it("渲染与之前一致", () => {
|
||||
const { container } = render(<UserDetail user={mockUser} />);
|
||||
expect(container).toMatchSnapshot();
|
||||
});
|
||||
```
|
||||
|
||||
> [!warning] 快照的陷阱
|
||||
> - 时间戳、随机 ID 等动态内容会导致每次快照不同 → 用 `sanitize` 处理
|
||||
> - 盲目更新快照（`-u`）等于放弃测试价值 → **每次 diff 都要人工审查**
|
||||
> - 配合确定性断言一起使用，不要只做快照断言
|
||||
|
||||
### 查询方法速查表
|
||||
|
||||
> [!question] 思考：getBy、queryBy、findBy 我该用哪个？
|
||||
> React Testing Library 提供三类查询，它们的**行为差异直接决定测试的健壮性**。
|
||||
|
||||
| 前缀 | 匹配不到时 | 典型场景 |
|
||||
|------|-----------|---------|
|
||||
| `getBy*` | **抛异常**（测试失败） | 验证元素**必须存在** |
|
||||
| `queryBy*` | 返回 `null` | 验证元素**不应存在**（配合 `.not.toBeInTheDocument()`） |
|
||||
| `findBy*` | **超时后抛异常** | 等待**异步出现**的元素（内部自动 await） |
|
||||
|
||||
```tsx
|
||||
// getBy — 必须有，没有就失败（同步）
|
||||
const submitBtn = screen.getByRole("button", { name: /submit/i });
|
||||
|
||||
// queryBy — 验证"不存在"（同步，推荐优先于 findBy 做否定断言）
|
||||
expect(screen.queryByRole("alert")).not.toBeInTheDocument();
|
||||
|
||||
// findBy — 等待异步出现的元素（内部封装了 waitFor + polling）
|
||||
const successMsg = await screen.findByText("Saved!");
|
||||
|
||||
// ✅ 避免：手动写 waitFor + getBy（findBy 更简洁）
|
||||
// await waitFor(() => expect(screen.getByText("Saved!")).toBeInTheDocument());
|
||||
|
||||
// getAllBy — 匹配多个元素
|
||||
const checkboxes = screen.getAllByRole("checkbox");
|
||||
expect(checkboxes).toHaveLength(3);
|
||||
```
|
||||
|
||||
> [!tip] 查询优先级原则
|
||||
> 按以下顺序选择查询方式，越靠前的优先级越高：
|
||||
>
|
||||
> `role` → `label` → `text` → `testID` → `screen`（最后手段）
|
||||
>
|
||||
> **永远不要**用 `container.querySelector(".css-class")`——样式变了测试就挂了。
|
||||
|
||||
---
|
||||
|
||||
## Mock 异步操作
|
||||
|
||||
### vi.mock() — 模块级 Mock
|
||||
|
||||
```tsx
|
||||
// 内联 Mock，隔离 API 依赖
|
||||
vi.mock("../api/user", () => ({
|
||||
getUser: vi.fn().mockResolvedValue({ id: 1, name: "Alice" }),
|
||||
updateUser: vi.fn().mockResolvedValue(undefined),
|
||||
}));
|
||||
```
|
||||
|
||||
### Mock Fetch / Axios
|
||||
|
||||
```tsx
|
||||
it("loading 态在请求完成后消失", async () => {
|
||||
vi.mocked(fetch).mockResolvedValueOnce({
|
||||
// 推荐：用 vi.spyOn 包装全局 fetch
|
||||
vi.spyOn(global, "fetch").mockResolvedValueOnce({
|
||||
ok: true,
|
||||
json: async () => [{ id: 1, name: "Test" }],
|
||||
} as Response);
|
||||
@@ -167,7 +240,7 @@ it("loading 态在请求完成后消失", async () => {
|
||||
});
|
||||
|
||||
it("网络错误显示错误提示", async () => {
|
||||
vi.mocked(fetch).mockRejectedValueOnce(new Error("Network error"));
|
||||
vi.spyOn(global, "fetch").mockRejectedValueOnce(new Error("Network error"));
|
||||
|
||||
render(<TodoList />);
|
||||
|
||||
@@ -177,6 +250,13 @@ it("网络错误显示错误提示", async () => {
|
||||
});
|
||||
```
|
||||
|
||||
> [!note] API Mock 方案选型
|
||||
> - **vi.mock() / vi.spyOn**：适合单元测试，快速隔离依赖，但无法模拟完整网络流程
|
||||
> - **MSW (Mock Service Worker)**：通过 Service Worker 拦截真实网络请求，适用于集成测试；与生产行为最接近
|
||||
> - **建议**：组件层用 vi.mock；集成流用 MSW
|
||||
|
||||
---
|
||||
|
||||
## Hook 测试
|
||||
|
||||
```tsx
|
||||
@@ -188,9 +268,10 @@ describe("useDebounce", () => {
|
||||
afterEach(() => vi.useRealTimers());
|
||||
|
||||
it("值不变时返回原始值", () => {
|
||||
const { result } = renderHook(({ value }) => useDebounce(value, 300), {
|
||||
initialProps: { value: "hello", delay: 300 },
|
||||
});
|
||||
const { result } = renderHook(
|
||||
({ value }) => useDebounce(value, 300),
|
||||
{ initialProps: { value: "hello" } }
|
||||
);
|
||||
|
||||
expect(result.current).toBe("hello");
|
||||
});
|
||||
@@ -210,6 +291,100 @@ describe("useDebounce", () => {
|
||||
});
|
||||
```
|
||||
|
||||
> [!tip] Hook 测试的关键模式
|
||||
> - **时间控制**：用 `vi.useFakeTimers()` + `act(() => vi.advanceTimersByTime(n))` 精确控制异步时序，不依赖真实等待
|
||||
> - **cleanup**：每个 `beforeEach` 对应独立的渲染上下文，`rerender` 模拟 props 更新时的行为
|
||||
> - **不要断言内部变量**：只检查 `result.current`（返回值），就像组件只暴露 props 一样
|
||||
|
||||
---
|
||||
|
||||
## 集成测试模式
|
||||
|
||||
```tsx
|
||||
// 模拟一个完整的用户操作流程
|
||||
describe("<SignupForm /> — 集成测试", () => {
|
||||
it("完整注册流程：填写 → 提交 → 跳转", async () => {
|
||||
// 1. Mock API 响应
|
||||
vi.mock("../api/auth", () => ({
|
||||
register: vi.fn().mockResolvedValue({ token: "abc123" }),
|
||||
}));
|
||||
|
||||
// 2. 渲染表单
|
||||
render(<SignupForm />);
|
||||
|
||||
// 3. 模拟用户输入（userEvent 更符合真实行为）
|
||||
const emailInput = screen.getByLabelText(/email/i);
|
||||
const passwordInput = screen.getByLabelText(/password/i);
|
||||
|
||||
await userEvent.type(emailInput, "alice@example.com");
|
||||
await userEvent.type(passwordInput, "SecurePass123!");
|
||||
|
||||
// 4. 提交
|
||||
const submitBtn = screen.getByRole("button", { name: /sign up/i });
|
||||
await userEvent.click(submitBtn);
|
||||
|
||||
// 5. 验证结果
|
||||
await screen.findByText("Account created!");
|
||||
});
|
||||
|
||||
it("重复邮箱提示错误", async () => {
|
||||
vi.mock("../api/auth", () => ({
|
||||
register: vi.fn().mockRejectedValue(new Error("Email already exists")),
|
||||
}));
|
||||
|
||||
render(<SignupForm />);
|
||||
|
||||
const emailInput = screen.getByLabelText(/email/i);
|
||||
await userEvent.type(emailInput, "exists@example.com");
|
||||
await userEvent.click(screen.getByRole("button", { name: /sign up/i }));
|
||||
|
||||
await screen.findByText("Email already exists");
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
> [!important] 集成测试的设计要点
|
||||
> - **一次测一个完整流程**，不要拆成原子步骤——这样即使中间环节变动，只要最终行为一致就不需要改测试
|
||||
> - **Mock 所有外部依赖**（API、localStorage、WebSocket），但不 mock 内部逻辑
|
||||
> 集成测试的目标是：**确认多个组件协同工作后，用户得到了正确的反馈**
|
||||
|
||||
---
|
||||
|
||||
## 错误边界测试
|
||||
|
||||
```tsx
|
||||
import { ErrorBoundary } from "./ErrorBoundary";
|
||||
|
||||
describe("<ErrorBoundary />", () => {
|
||||
// 让被包裹的组件抛出错误
|
||||
function BrokenComponent() {
|
||||
throw new Error("Render failed");
|
||||
}
|
||||
|
||||
it("捕获渲染错误并显示 fallback UI", () => {
|
||||
render(
|
||||
<ErrorBoundary fallback={<div>Something went wrong</div>}>
|
||||
<BrokenComponent />
|
||||
</ErrorBoundary>
|
||||
);
|
||||
|
||||
expect(screen.getByText("Something went wrong")).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it("未发生错误时正常渲染子内容", () => {
|
||||
render(
|
||||
<ErrorBoundary>
|
||||
<span>Safe content</span>
|
||||
</ErrorBoundary>
|
||||
);
|
||||
|
||||
expect(screen.getByText("Safe content")).toBeInTheDocument();
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## E2E 测试选择
|
||||
|
||||
| 工具 | 适用场景 | 特点 |
|
||||
@@ -222,4 +397,11 @@ describe("useDebounce", () => {
|
||||
> - E2E 只应覆盖**关键用户旅程**（登录、下单、支付）
|
||||
> - 不要为每个页面的每个字段写 E2E——那属于集成测试的范畴
|
||||
|
||||
---
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[07-自定义 Hooks]] — 自定义 Hook 的设计与测试模式
|
||||
- [[09-状态管理]] — 全局状态管理（Zustand / Redux Toolkit）的测试策略
|
||||
- [[13-并发特性]] — Suspense、Transitions 的测试注意事项
|
||||
- [[15-性能优化]] — 性能回归测试：React Testing Library + Performance Assertions
|
||||
|
||||
Reference in New Issue
Block a user