Front-End-Checklist 集成测试实战为关键工作流编写 API 与组件级测试【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist单元测试验证单个函数在隔离状态下的行为却无法捕获函数之间协同工作时的接线错误——一个完全正确的校验函数和一个正确的数据库函数仍然可能在错误地被装配在一起时一起失败。集成测试Integration Tests正是为了在缺陷进入生产环境之前发现这类接线 bug而存在因为在生产环境中诊断这类问题的成本要高得多。本指南以 Front-End-Checklist 仓库的 integration-testing 技能文档 及其完整实现参考为主体结合仓库内真实的 Jest、Playwright 配置与测试用例讲解如何在 API 路由、服务与数据库、组件与状态管理这些系统边界处编写高价值的集成测试并给出可落地的验证标准与 CI 强制手段。读完本文你将能够识别代码库中的关键集成点、编写可复用的 API 与组件集成测试、判断哪些场景适合集成测试而哪些更适合单元测试并在 CI 中确保自动化真正阻断回归。集成测试单元测试与 E2E 测试之间的关键一层在 Front-End-Checklist 的测试技能体系中集成测试的定位非常清晰集成测试验证多个单元在连接之后能正确协同工作测试应当发生在系统不同部分交汇的边界上优先使用真实数据库测试库或内存库而不是把一切都 mock 掉覆盖 happy path 与最关键的错误路径。与单元测试、E2E 测试的分工从仓库的 TESTING-STRATEGY.md 可以看到不同层级的测试应有不同的覆盖率目标测试层级覆盖率目标关注点单元测试80%–90%单个函数/组件的隔离行为集成测试70%–80%单元之间的真实协作与接线正确性E2E 测试50%–60%关键用户旅程从浏览器视角验证端到端流程这套分层策略直接体现在当覆盖率超过 80%–90% 后边际收益递减把时间投入到集成/E2E 测试上更划算的原则中。集成测试恰好弥补了单元测试的盲区单元测试各自通过不代表它们装配后的系统行为正确。Check如何定位代码库中的关键集成点编写集成测试的第一步是识别当前代码库中的关键集成点。以本仓库为例搜索源码可以定位到三类典型的集成边界API 路由调用服务层如 apps/web/app/api/ 下的checklists、profile、rules/[ruleId]/feedback等路由它们组合了鉴权repo/auth、数据访问Prisma与遥测等模块服务层与数据库交互如 packages/data-layer/src/queries.ts 与 mutations.ts 封装的读写逻辑是数据层的核心集成点组件与状态管理交互如 apps/web/components 中依赖 hooks 与远程数据的组件树。判断标准是这些边界是否已经被测试覆盖如果某个关键路径只有单元测试或完全没有测试它就是集成测试的首选目标。Fix为关键路径编写集成测试API 路由 数据库完整服务端链路参考文档给出了一个标准的 API 集成测试模板使用supertest发起真实 HTTP 请求、用测试数据库执行迁移与种子数据// test/api/users.integration.test.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) }) })这个示例展示了集成测试的三个关键动作构造真实请求supertest(app)、验证响应契约状态码 响应体、回查数据库确认副作用db(users).where(...)。错误路径重复邮箱返回 400与 happy path 同等重要。仓库中对应的真实实践可参考 apps/web/app/api/checklists/tests/route.test.ts该测试直接引入路由的GET/POST处理器在jest-environment node下模拟鉴权会话repo/auth/auth的getSession与 Prisma 数据访问层逐场景断言列表读取与创建行为的响应结构并在beforeEach中通过jest.clearAllMocks()保证用例隔离。这是在真实边界测试、只 mock 外部副作用原则的体现。组件 提交 API 响应 UI 反馈前端集成对于前端组件参考文档推荐使用 React Testing Library userEvent模拟真实用户操作配合 MSWMock Service Worker在server.use(...)中按用例注入不同的 API 响应// test/UserProfileForm.integration.test.jsx describe(UserProfileForm, () { it(submits updated profile and shows success message, async () { const user userEvent.setup() render(/* UserProfileForm / */) // 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 }) })这段测试的价值在于一次断言覆盖了整条链路表单填写 → 提交 → API 调用 → 状态更新 → UI 反馈渲染。错误用例通过 MSW 覆盖 API 返回 422 校验失败时的 UI 表现。仓库的组件测试配置为其提供了完整的运行环境支撑apps/web/jest.setup.cjs 引入了testing-library/jest-dom的自定义匹配器toBeInTheDocument、not.toBeEmptyDOMElement等并补齐了 jsdom 环境缺失的TextDecoder/TextEncoder与window.matchMediaapps/web/jest.config.cjs 通过next/jest加载 Next.js 配置并把frontendchecklist/rules、repo/*等 workspace 包统一映射到源码路径使测试能够直接命中真实实现而非编译产物。页面级集成测试的典型范例可参考 apps/web/app/(site)/checklists/[slug]/tests/page.test.tsx渲染真实页面组件、只 mock 掉导航与 SEO 等边界模块然后断言标题、描述、难度、时长与操作栏等 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选择标准的本质是是否有外部依赖与状态交织纯函数与无外部依赖的组件没有接线可言单元测试足够而涉及数据读写、鉴权会话、跨模块状态流转的流程才是集成测试的主战场。这与 TESTING-STRATEGY.md 中重视业务关键路径、覆盖错误处理路径、测试数据校验与安全边界的最佳实践完全一致。在 Front-End-Checklist 中落地覆盖率阈值与测试运行仓库通过共享配置把集成测试的底线固化到所有包中。jest.base.cjs 定义了全局覆盖率阈值Statements / Lines / Functions80%Branches70%对条件逻辑更务实的指标同时产出text终端即时反馈、lcovCI 集成与html可视化报告三种格式的覆盖率报告。apps/web/jest.config.cjs 继承该阈值并将其应用于 Next.js 应用同时通过testPathIgnorePatterns将e2e/目录排除出 Jest 范围——浏览器端 E2E 交由 apps/web/playwright.config.ts 负责默认BASE_URL为http://127.0.0.1:3080CI 下自动重试 2 次并在 chromium/firefox/webkit 三个浏览器项目上并行运行。运行命令源自 TESTING-STRATEGY.md# 开发模式watch pnpm test # 带覆盖率报告运行 pnpm test:coverage # CI 模式不监听、带覆盖率 pnpm test:ci # 运行单个测试文件 pnpm test Counter.test.tsx针对浏览器端的关键流程集成apps/e2e/README.md 描述了基于 Playwright Page Object Model 的 E2E 体系支持smoke、critical、visual、slow标签分类、--shard分片并行以及 trace 调试在集成测试之上这类测试进一步验证完整用户旅程如登录 → 会话 → 受保护路由。测试策略文档还明确了四层执行机制本地 Jest 覆盖率未达标即失败 → pre-commit 检查暂存文件 → pre-push 全量测试 → CI/CD 阻断合并。质量判定标准与验证清单参考文档要求以以下权威标准校验集成测试的实现是否达标用这些参考作为测试或监控策略在交付工作流中应如何表现的标准对照Playwright 官方文档检查实现是否合格对照Testing Library 指导原则以用户视角查询、避免测试实现细节检查实现是否合格。验证清单Verification实现一个集成测试后按以下 4 条逐一验证才算真正满足规则本地复现失败运行相关测试或 CI 步骤确认在规则被违反时测试确实失败阻断回归而非只报警确保自动化能够阻断回归而不是仅打印警告覆盖代表性高风险流至少覆盖一个高风险的流程、组件或路由阈值与断言入库将覆盖率阈值或断言保存在版本控制中使改动保持可审查。第 2 条尤其值得强调一条只输出警告却永远放行的测试会给人虚假的安全感。仓库的做法是将阈值写进jest.base.cjs并在coverageThreshold中全局生效——覆盖率下降时 Jest 直接以非零退出码失败从而在 CI 层面形成硬性阻断。这一机制与 Skills 文档中 integration-testing 的 Code Review 要求审查测试、CI 工作流与执行点标出规则未被自动验证或失败未阻断回归的具体缺口形成闭环。总结把集成测试变成 CI 中的硬约束围绕 Front-End-Checklist 的 integration-testing 技能完整的实践路径是先用边界视角审视代码库找出关键集成点Check再按API 数据库与组件 API UI 反馈两类模板编写测试Fix以取舍清单控制测试范围最后用覆盖率阈值与 CI 阻断机制让规则持续被验证而非仅被记录。正如测试策略文档所强调的目标不是 100% 覆盖率而是对代码正确性与可维护性的信心——集成测试正是把单元测试的信心延伸到系统真实协作边界上的那一层保障。【免费下载链接】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），仅供参考 Front-End-Checklist 集成测试实战：为关键工作流编写 API 与组件级测试
Front-End-Checklist 集成测试实战为关键工作流编写 API 与组件级测试【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist单元测试验证单个函数在隔离状态下的行为却无法捕获函数之间协同工作时的接线错误——一个完全正确的校验函数和一个正确的数据库函数仍然可能在错误地被装配在一起时一起失败。集成测试Integration Tests正是为了在缺陷进入生产环境之前发现这类接线 bug而存在因为在生产环境中诊断这类问题的成本要高得多。本指南以 Front-End-Checklist 仓库的 integration-testing 技能文档 及其完整实现参考为主体结合仓库内真实的 Jest、Playwright 配置与测试用例讲解如何在 API 路由、服务与数据库、组件与状态管理这些系统边界处编写高价值的集成测试并给出可落地的验证标准与 CI 强制手段。读完本文你将能够识别代码库中的关键集成点、编写可复用的 API 与组件集成测试、判断哪些场景适合集成测试而哪些更适合单元测试并在 CI 中确保自动化真正阻断回归。集成测试单元测试与 E2E 测试之间的关键一层在 Front-End-Checklist 的测试技能体系中集成测试的定位非常清晰集成测试验证多个单元在连接之后能正确协同工作测试应当发生在系统不同部分交汇的边界上优先使用真实数据库测试库或内存库而不是把一切都 mock 掉覆盖 happy path 与最关键的错误路径。与单元测试、E2E 测试的分工从仓库的 TESTING-STRATEGY.md 可以看到不同层级的测试应有不同的覆盖率目标测试层级覆盖率目标关注点单元测试80%–90%单个函数/组件的隔离行为集成测试70%–80%单元之间的真实协作与接线正确性E2E 测试50%–60%关键用户旅程从浏览器视角验证端到端流程这套分层策略直接体现在当覆盖率超过 80%–90% 后边际收益递减把时间投入到集成/E2E 测试上更划算的原则中。集成测试恰好弥补了单元测试的盲区单元测试各自通过不代表它们装配后的系统行为正确。Check如何定位代码库中的关键集成点编写集成测试的第一步是识别当前代码库中的关键集成点。以本仓库为例搜索源码可以定位到三类典型的集成边界API 路由调用服务层如 apps/web/app/api/ 下的checklists、profile、rules/[ruleId]/feedback等路由它们组合了鉴权repo/auth、数据访问Prisma与遥测等模块服务层与数据库交互如 packages/data-layer/src/queries.ts 与 mutations.ts 封装的读写逻辑是数据层的核心集成点组件与状态管理交互如 apps/web/components 中依赖 hooks 与远程数据的组件树。判断标准是这些边界是否已经被测试覆盖如果某个关键路径只有单元测试或完全没有测试它就是集成测试的首选目标。Fix为关键路径编写集成测试API 路由 数据库完整服务端链路参考文档给出了一个标准的 API 集成测试模板使用supertest发起真实 HTTP 请求、用测试数据库执行迁移与种子数据// test/api/users.integration.test.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) }) })这个示例展示了集成测试的三个关键动作构造真实请求supertest(app)、验证响应契约状态码 响应体、回查数据库确认副作用db(users).where(...)。错误路径重复邮箱返回 400与 happy path 同等重要。仓库中对应的真实实践可参考 apps/web/app/api/checklists/tests/route.test.ts该测试直接引入路由的GET/POST处理器在jest-environment node下模拟鉴权会话repo/auth/auth的getSession与 Prisma 数据访问层逐场景断言列表读取与创建行为的响应结构并在beforeEach中通过jest.clearAllMocks()保证用例隔离。这是在真实边界测试、只 mock 外部副作用原则的体现。组件 提交 API 响应 UI 反馈前端集成对于前端组件参考文档推荐使用 React Testing Library userEvent模拟真实用户操作配合 MSWMock Service Worker在server.use(...)中按用例注入不同的 API 响应// test/UserProfileForm.integration.test.jsx describe(UserProfileForm, () { it(submits updated profile and shows success message, async () { const user userEvent.setup() render(/* UserProfileForm / */) // 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 }) })这段测试的价值在于一次断言覆盖了整条链路表单填写 → 提交 → API 调用 → 状态更新 → UI 反馈渲染。错误用例通过 MSW 覆盖 API 返回 422 校验失败时的 UI 表现。仓库的组件测试配置为其提供了完整的运行环境支撑apps/web/jest.setup.cjs 引入了testing-library/jest-dom的自定义匹配器toBeInTheDocument、not.toBeEmptyDOMElement等并补齐了 jsdom 环境缺失的TextDecoder/TextEncoder与window.matchMediaapps/web/jest.config.cjs 通过next/jest加载 Next.js 配置并把frontendchecklist/rules、repo/*等 workspace 包统一映射到源码路径使测试能够直接命中真实实现而非编译产物。页面级集成测试的典型范例可参考 apps/web/app/(site)/checklists/[slug]/tests/page.test.tsx渲染真实页面组件、只 mock 掉导航与 SEO 等边界模块然后断言标题、描述、难度、时长与操作栏等 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选择标准的本质是是否有外部依赖与状态交织纯函数与无外部依赖的组件没有接线可言单元测试足够而涉及数据读写、鉴权会话、跨模块状态流转的流程才是集成测试的主战场。这与 TESTING-STRATEGY.md 中重视业务关键路径、覆盖错误处理路径、测试数据校验与安全边界的最佳实践完全一致。在 Front-End-Checklist 中落地覆盖率阈值与测试运行仓库通过共享配置把集成测试的底线固化到所有包中。jest.base.cjs 定义了全局覆盖率阈值Statements / Lines / Functions80%Branches70%对条件逻辑更务实的指标同时产出text终端即时反馈、lcovCI 集成与html可视化报告三种格式的覆盖率报告。apps/web/jest.config.cjs 继承该阈值并将其应用于 Next.js 应用同时通过testPathIgnorePatterns将e2e/目录排除出 Jest 范围——浏览器端 E2E 交由 apps/web/playwright.config.ts 负责默认BASE_URL为http://127.0.0.1:3080CI 下自动重试 2 次并在 chromium/firefox/webkit 三个浏览器项目上并行运行。运行命令源自 TESTING-STRATEGY.md# 开发模式watch pnpm test # 带覆盖率报告运行 pnpm test:coverage # CI 模式不监听、带覆盖率 pnpm test:ci # 运行单个测试文件 pnpm test Counter.test.tsx针对浏览器端的关键流程集成apps/e2e/README.md 描述了基于 Playwright Page Object Model 的 E2E 体系支持smoke、critical、visual、slow标签分类、--shard分片并行以及 trace 调试在集成测试之上这类测试进一步验证完整用户旅程如登录 → 会话 → 受保护路由。测试策略文档还明确了四层执行机制本地 Jest 覆盖率未达标即失败 → pre-commit 检查暂存文件 → pre-push 全量测试 → CI/CD 阻断合并。质量判定标准与验证清单参考文档要求以以下权威标准校验集成测试的实现是否达标用这些参考作为测试或监控策略在交付工作流中应如何表现的标准对照Playwright 官方文档检查实现是否合格对照Testing Library 指导原则以用户视角查询、避免测试实现细节检查实现是否合格。验证清单Verification实现一个集成测试后按以下 4 条逐一验证才算真正满足规则本地复现失败运行相关测试或 CI 步骤确认在规则被违反时测试确实失败阻断回归而非只报警确保自动化能够阻断回归而不是仅打印警告覆盖代表性高风险流至少覆盖一个高风险的流程、组件或路由阈值与断言入库将覆盖率阈值或断言保存在版本控制中使改动保持可审查。第 2 条尤其值得强调一条只输出警告却永远放行的测试会给人虚假的安全感。仓库的做法是将阈值写进jest.base.cjs并在coverageThreshold中全局生效——覆盖率下降时 Jest 直接以非零退出码失败从而在 CI 层面形成硬性阻断。这一机制与 Skills 文档中 integration-testing 的 Code Review 要求审查测试、CI 工作流与执行点标出规则未被自动验证或失败未阻断回归的具体缺口形成闭环。总结把集成测试变成 CI 中的硬约束围绕 Front-End-Checklist 的 integration-testing 技能完整的实践路径是先用边界视角审视代码库找出关键集成点Check再按API 数据库与组件 API UI 反馈两类模板编写测试Fix以取舍清单控制测试范围最后用覆盖率阈值与 CI 阻断机制让规则持续被验证而非仅被记录。正如测试策略文档所强调的目标不是 100% 覆盖率而是对代码正确性与可维护性的信心——集成测试正是把单元测试的信心延伸到系统真实协作边界上的那一层保障。【免费下载链接】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），仅供参考