呱呱 前端开发
前端测试策略：优先 E2E、少 mock、测行为而非实现
在决定写什么类型的测试、编写或审查前端测试代码时，用 E2E 优先、最小化 mock、只测纯函数单元测试的原则来保证测试真实可信。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 49/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
前端测试策略：优先 E2E、少 mock通用
解决思路
- 默认优先写 E2E 测试，覆盖真实用户流程；只有纯函数才写单元测试。
- 不要对 React 组件做单元测试，通过 E2E 自然覆盖组件，或干脆不测。
- 保持 mock 简单；如果需要 3 个以上 mock，就改写成 E2E 测试。
- E2E 测试放在 `e2e/tests/` 目录下，而不是 `frontend/`。
- E2E 测试用 `test.describe` 组织，并在 `test.beforeEach` 中通过 `createTestingAccount`、`addAccountBalance` 等工具准备账号和余额等前置数据。
- E2E 选择器优先级为 role > label > text > testid：优先用 `page.getByRole(...)`、`page.getByLabel(...)`，无可用可访问选择器时才用 `page.getByTestId(...)`，避免用 `.btn-primary` 这类 CSS 选择器。
- 单元测试只针对纯函数，并与源文件放在一起（如 `app/utils/format.test.ts`），用 vitest 的 `describe`/`test`/`expect` 编写。
- 单元测试中如需 mock 网络请求，用 MSW 的 `mockServer.use(http.get(...))` 做简单 mock，而不是 `vi.mock` 多个模块。
- 写测试或审查测试代码时，按「测行为而非实现」的原则检查：断言用户能看到和做到的内容。
- 重构测试时，把复杂的组件单元测试和多重 mock 的测试迁移为 E2E 测试。
- E2E 测试使用 Playwright（`@playwright/test`），单元测试配置在 `vitest.config.ts`，全局 setup 在 `vitest.setup.ts`。
适用边界 · 注意事项
- 需要验证纯函数逻辑（如格式化、计算）时，不要写 E2E，直接写单元测试。
- 当测试需要 3 个以上 mock 才能运行时，不要继续堆 mock，应改为 E2E 测试。
- 不要为了测 React 组件渲染细节而写组件单元测试。