Front-End-Checklist 集成测试规则解读：为核心工作流编写高价值的集成测试

Front-End-Checklist 集成测试规则解读为核心工作流编写高价值的集成测试【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文围绕 Front-End-Checklist 仓库中的integration-testing规则规则详情、完整参考展开系统讲解集成测试的目标、API 与组件两条主流写法、高价值测试靶点的取舍并结合本仓库的 Jest 覆盖率阈值与 Playwright E2E 基建说明如何把集成测试覆盖关键工作流真正落地为可持续执行的工程规范。读完本文你将掌握集成测试与单元测试/E2E 测试的边界、可复制的 API 与组件集成测试代码模板以及一套可在 CI 中强制执行的回归拦截策略。规则概览为什么关键工作流需要集成测试在 Front-End-Checklist 的测试体系中integration-testing被标记为Priority: high · Difficulty: intermediate · Time: 30 min见 SKILL 元数据其核心主张是Integration tests verify that separate units of code work correctly when connected together, catching the bugs that unit tests cant.即集成测试验证多个代码单元在连接在一起时是否协同正确捕获单元测试无法发现的接线wiring缺陷。该规则在内容层被归类为testing/integration子类别见 integration-testing.mdx 的 frontmatter与unit-tests、e2e-testing、contract-testing、mutation-testing等规则互为补充单元测试验证单个函数在隔离环境下的行为集成测试验证模块间的真实交互覆盖的层级比单元测试高、比 E2E 更广E2E 测试在真实浏览器中模拟完整用户旅程速度最慢、数量最少契约测试与集成测试同属testing/integration区域常被一起评审。规则文档给出的快速参考同样值得铭记集成测试要在系统各部分交汇的边界上进行测试优先使用真实数据库测试库或内存库而非把一切 mock 掉并同时覆盖 happy path 与最关键的错误路径。为什么它重要单元测试正确系统仍可能整体失败原文档的 Why It Matters 描述了一个非常典型的故障模型一个完全正确的校验函数与一个完全正确的数据库函数在接线不当时仍会整体失败——参数顺序颠倒、返回结构不匹配、事务未提交、异步时序错误等都是单测环境下无法暴露的问题。这类接线 bug一旦流入生产环境诊断成本极高因为错误发生在多个模块的边界而非某个模块内部。这也是本仓库在 TESTING-STRATEGY.md 中强调One good integration test can be worth multiple unit tests的原因——集成测试用更少的用例覆盖更长的调用链是投资回报最高的测试层级之一。实战一API 路由 数据库查询的集成测试规则文档提供了完整的 API 集成测试模板references/rule.md核心思路是用真实数据库 HTTP 客户端端到端打穿路由 → 业务逻辑 → 数据库整条服务端链路。// test/api/users.integration.test.js import { describe, it, expect, beforeAll, afterAll } from vitest import supertest from supertest import { app } from ../src/app.js import { db } from ../src/db.js describe(POST /api/users, () { beforeAll(async () { await db.migrate.latest() await db.seed.run() }) afterAll(async () { await db.destroy() }) it(creates a user with valid data, async () { const response await supertest(app) .post(/api/users) .send({ name: Alice, email: aliceexample.com }) .expect(201) expect(response.body).toMatchObject({ id: expect.any(Number), name: Alice, email: aliceexample.com }) // Verify it was actually saved const saved await db(users).where({ email: aliceexample.com }).first() expect(saved).toBeDefined() }) it(returns 400 for duplicate email, async () { await supertest(app) .post(/api/users) .send({ name: Bob, email: existingexample.com }) .expect(400) }) })该模板值得逐点拆解生命周期管理beforeAll中先跑数据库迁移db.migrate.latest()再灌种子数据db.seed.run()保证每个测试会话有确定性的初始状态afterAll中关闭数据库连接db.destroy()避免资源泄漏。这是集成测试与单元测试最显著的区别——它依赖真实基础设施而不是 mock。断言真正落地第一个用例不仅断言 HTTP 响应的状态码与响应体201toMatchObject还反向查库db(users).where(...).first()验证数据确实持久化。这一响应断言 落库断言的双重验证正是集成测试比单元测试更能发现接线问题的关键。覆盖错误路径第二个用例验证重复邮箱返回400证明测试不止覆盖 happy path还要覆盖最关键的错误分支规则的 Quick Reference 明确要求Test happy paths and the most critical error paths。规则文档推荐的工具链是Vitest配合 jsdom SupertestHTTP API 集成见 integration-testing.mdx 的 tools 字段对 React/Vue/Angular 组件则使用Testing Library。实战二React 组件 状态管理 API 的组件集成测试第二类典型场景是组件集成测试。规则文档给出的例子覆盖了表单交互 → API 调用 → 状态更新 → UI 反馈的完整链路// test/UserProfileForm.integration.test.jsx import { render, screen, waitFor } from testing-library/react import userEvent from testing-library/user-event import { QueryClientProvider } from tanstack/react-query import { UserProfileForm } from ../src/components/UserProfileForm import { server } from ./mocks/server import { rest } from msw describe(UserProfileForm, () { it(submits updated profile and shows success message, async () { const user userEvent.setup() render( QueryClientProvider client{queryClient} UserProfileForm userId{1} / /QueryClientProvider ) // Fill in the form const nameInput screen.getByLabelText(Full name) await user.clear(nameInput) await user.type(nameInput, Alice Updated) // Submit await user.click(screen.getByRole(button, { name: Save changes })) // Verify success feedback (tests form API call state update UI render) await waitFor(() { expect(screen.getByText(Profile saved successfully)).toBeInTheDocument() }) }) it(shows field errors when API returns validation failure, async () { server.use( rest.put(/api/users/:id, (req, res, ctx) res(ctx.status(422), ctx.json({ errors: { name: Name is too long } })) ) ) // ... test error display }) })这个例子的关键设计在于Testing Library 的用户视角原则用getByLabelText、getByRole等可访问性查询定位元素模拟真实用户的操作方式清除输入、逐字符输入、点击按钮而不是操作组件内部状态。这正是规则 Standards 中以 Testing Library Guiding Principles 为准绳的体现。真实状态管理组件被包裹在QueryClientProvider中配合tanstack/react-query的真实缓存与请求生命周期——测试的不是被 mock 死的组件而是组件 状态管理这一整体。网络层用 MSW 拦截通过server.use(rest.put(...))精确注入 422 校验失败响应验证 UI 的错误展示分支。这里只 mock 网络边界HTTP而非业务逻辑与用真实数据库、不 mock 一切的原则一脉相承。断言落在 UI 反馈上成功用例用waitFor等待Profile saved successfully出现把表单提交 API 调用 状态更新 UI 渲染四段链路一次性验证完毕。取舍清单该测什么、该跳过什么规则文档给出一份高价值的集成测试靶点清单可直接作为评审清单使用High-value integration test targets: ✓ API routes database queries (the full server-side stack) ✓ Form components submission API response UI feedback ✓ Authentication flows (login → session → protected route) ✓ Shopping cart checkout order creation ✓ File upload processing storage thumbnail display ✓ Search input query → results display Skip (better as unit tests): ✗ Pure utility functions ✗ Simple transformations ✗ Components with no external dependencies挑选原则非常清晰集成测试只投资在多个单元交互的边界上。纯工具函数、简单数据变换、无外部依赖的组件用单元测试即可覆盖写成集成测试只会拖慢套件、增加维护成本。鉴于此规则在 Front-End-Checklist 中被设定为 30 分钟的快速实践项从清单中挑选 1~2 个最高风险的流程优先覆盖是性价比最高的起步方式。仓库工程实践覆盖率阈值与回归拦截规则文档的 Verification 部分给出了四条验收标准其中最关键的是让自动化拦截回归而不是只打印警告Ensure the automation blocks regressions instead of only printing warnings以及把阈值或断言保留在版本控制中使变更可评审。Front-End-Checklist 仓库自身就是这套标准的最佳样本1. 全局覆盖率阈值。仓库根目录的 jest.base.cjs 定义了全局覆盖率红线statements/lines/functions 各 80%branches 70%并统一配置text、lcov、html三种报告格式所有子包的 Jest 配置如 apps/web/jest.config.cjs 中的coverageThreshold.global都引用这一份基线。这就是阈值保留在版本控制中的落地方式——阈值是代码的一部分随 PR 一起评审、一起演进。2. 分层目标。TESTING-STRATEGY.md 进一步给出分层策略单元测试 80–90%、集成测试 70–80%、E2E 聚焦关键用户旅程50–60%并明确从 80% 追到 100% 的投入不如投入到集成/E2E 测试上——与规则文档单元测试正确但接线错误的论述形成呼应。对关键路径业务核心功能、错误处理路径、数据校验与安全边界优先测试并允许对生成文件、配置、类型定义、测试工具等合理豁免。3. 多级强制执行。覆盖率阈值在本地Jest 覆盖率不达标即失败、pre-commit对暂存文件检查、pre-push全量测试套件、CI/CD不满足要求即阻塞合并四级生效。任何只打印警告的弱化都会破坏这条链路因此规则文档特别强调自动化必须真正block regressions。4. 测试脚本。可在 apps/web/package.json 中看到配套命令pnpm testwatch 模式、pnpm test:coverage带覆盖率报告、pnpm test:ciCI 单 worker 无 watch、pnpm test:related按变更文件关联运行以及pnpm test:coverage:check输出 text-summary 与 json-summary 供 CI 断言。与 E2E 测试的分工集成测试应该比 E2E 覆盖更多场景规则文档在 relatedRules 中明确Integration tests are faster than E2E tests and should cover more scenarios。仓库的 E2E 基建apps/e2e/playwright.config.ts、apps/e2e/README.md给出了这条分工线的实践参照Playwright 配置默认启用 Chromium/Firefox/WebKit 三内核及 Mobile Chrome、Mobile Safari 五个 projectCI 下禁止test.only、失败自动重试 2 次并保留 trace 与截图通过webServer自动拉起pnpm dev端口 3080——这些都是为真实浏览器全链路设计的。Page Object ModelE2E 测试采用 POM 架构pages/封装页面交互、fixtures/提供自定义 fixture、config/test.config.ts集中管理超时/视口/性能阈值等常量测试从与浏览器交互上解放出来。职责分工E2E 专注少量关键用户旅程smoke、critical 等标签化分类而规则文档建议把API 数据库、表单 状态这类高频交互放在更快的集成测试层用数量换覆盖、用速度保频率。一个合理的测试金字塔因此是单元测试打底 → 集成测试用真实 DB/网络边界覆盖关键工作流 → E2E 只在真实浏览器中验证少数端到端旅程。落地检查清单Verification规则文档给出四项验收标准也是把本规则判定为满足的前提可结合 SKILL.md 的 aiContext 使用——评审时关注规则是否被持续自动验证而非仅被文档化本地运行相关测试或 CI 步骤确认违反规则时测试确实失败确保自动化会阻塞回归而不是只输出警告至少覆盖一个代表性的高风险流程、组件或路由把覆盖率阈值或断言保留在版本控制中保证变更可评审、可追踪。标准依据规则要求实现与 Playwright 文档 及 Testing Library 指导原则 保持一致原文出处见 references/rule.md 与 integration-testing.mdx 的 sources 字段。小结集成测试补上了单元测试与 E2E 之间的关键空缺它以模块边界为测试点用真实数据库、真实状态管理和最小化的网络 mock捕获接线阶段的缺陷。Front-End-Checklist 的这条规则给出了 APISupertest 真实 DB与组件Testing Library React Query MSW两套可直接复用的模板一套高价值靶点 / 应跳过项取舍清单以及80/70 覆盖率红线 四级强制执行的工程化落地样板。遵循它的做法就能把为关键工作流编写集成测试从一句口号变成 CI 中真正拦截回归的纪律。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考