AutoGPT 前端测试体系全解E2E、集成测试、单元测试与 MSW 模拟的选型与落地实践【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPTAutoGPT Platform 前端采用 PlaywrightE2E Vitest/RTL集成与单元测试 Storybook视觉的三层测试体系并通过 Orval 从 OpenAPI 规范自动生成 MSW 模拟数据。本文基于仓库中 前端测试规则文档完整梳理各测试类型的适用场景、文件组织规范与 MSW 拦截机制并深入到 Vitest 配置、覆盖率 fixture、Mock 服务源码层帮助你在 AutoGPT 前端项目中正确地选择测试层级、写出可复现且不易 flaky 的测试。一、测试类型总览四层金字塔与工具选型官方文档 autogpt_platform/frontend/src/tests/AGENTS.md 首先给出了一张测试类型速查表这是整个前端测试体系的骨架类型工具速度用途E2EPlaywright慢约 5s/条真实浏览器完整用户旅程IntegrationVitest RTL快约 100ms组件 模拟 APIUnitVitest RTL最快约 10ms单个函数/组件VisualStorybook ChromaticN/AUI 外观、设计系统从仓库实际配置看这套体系是真实落地的而非纸面规范Vitest 侧的入口配置见 vitest.config.mts测试环境使用happy-dom用例匹配src/**/*.test.tsx、src/**/*.test.ts与scripts/**/*.test.ts全局 setup 指向./src/tests/integrations/vitest.setup.tsx覆盖率由 v8 provider 生成textcobertura两种报告输出到./coverage目录并显式排除了测试文件、stories 文件、src/playwright/**与src/tests/**自身保证覆盖率只统计业务代码E2E 侧的规格文件集中在src/playwright/目录下如auth-happy-path.spec.ts、builder-happy-path.spec.ts、marketplace-happy-path.spec.ts等与文档中E2E 数量少、集中放置的定位一致。二、选型决策流程这条测试该写在哪个层级文档给出了一个清晰的决策树判断顺序是是否需要真实浏览器/后端 → 是否涉及 API 或复杂状态 → 是否关乎视觉外观Does it need a REAL browser/backend? ├─ YES → E2E (Playwright) └─ NO └─ Does it involve API calls or complex state? ├─ YES → Integration (Vitest RTL) └─ NO └─ Is it about visual appearance? ├─ YES → Storybook └─ NO → Unit (Vitest RTL)与之配套的是优先级矩阵明确了不同组件类型应当投入的测试精力组件类型测试优先级推荐测试Pages/Features最高IntegrationCustom Hooks中父级集成测试或共享 hook 单元测试Utility Functions高UnitOrganisms复杂组件高IntegrationMolecules中Unit StorybookAtoms中仅 Storybook** Atoms 通常足够简单Storybook 视觉测试即可覆盖。同时文档明确列出了不该测的内容第三方库内部实现Radix UI、React Query、CSS 样式细节交给 Storybook、无逻辑的简单 prop 透传组件、TypeScript 类型本身。这些负向清单与正向矩阵结合可以显著避免测试债的膨胀。三、E2E 测试Playwright 集中化管理与覆盖率采集3.1 适用场景与放置位置E2E 只用于必须在真实浏览器中才能验证的关键用户旅程认证流程登录、注册、登出支付或敏感交易依赖真实浏览器 API 的流程剪贴板、下载必须端到端打通的跨页面导航所有 E2E 用例集中放在src/playwright/*.spec.ts原因很简单——E2E 数量少且昂贵Golden Rules 第 5 条明确E2E is expensive集中放置便于维护。仓库中可以看到按 happy path 划分的规格文件auth-happy-path.spec.ts、builder-happy-path.spec.ts、publish-happy-path.spec.ts 等另有pages/Page Object与utils/辅助 fixture子目录与文档中File Organization一节完全对应。3.2 覆盖率 fixture为什么不能直接 import playwright/test文档中一条硬性规则值得特别展开E2E 测试必须从./coverage-fixture导入test和expect而不是playwright/test// 正确 import { test, expect } from ./coverage-fixture; // 错误——会绕过覆盖率采集 import { test, expect } from playwright/test;其实现见 coverage-fixture.ts逻辑是基于playwright/test的base扩展出一个自动 fixtureautoTestFixture在每条用例scope: test, auto: true开始时调用page.coverage.startJSCoverage({ resetOnNavigation: false })开启 V8 覆盖率采集用例结束后stopJSCoverage()并用monocart-reporter的addCoverageReport将结果挂到test.info()上最终汇入 Codecov 报告。源码中有两处防御性细节startJSCoverage用 try/catch 包裹非浏览器场景下 coverage API 可能不可用teardown 阶段的失败也被静默吞掉注释写明不要让覆盖率收尾失败掩盖真实的测试失败。这意味着绕过该 fixture 的代价不是少跑一个断言而是整条用例的 V8 覆盖率数据从 Codecov 报告中消失。四、集成测试页面级优先、UI 行为优先4.1 放置位置与拆分策略集成测试用于测试带依赖的组件API 调用、状态管理放置在与组件同级的__tests__目录中ComponentName/ __tests__/ main.test.tsx some-flow.test.tsx ComponentName.tsx useComponentName.ts文档明确主张从页面级开始不必为每个小组件写集成测试而应该先测页面例如/library/ __tests__/ main.test.tsx searching-agents.test.tsx agents-pagination.test.tsx page.tsx useLibraryPage.ts策略是先建一个main.test.tsx随着用例增长再拆分为更小的文件。这个策略把测试粒度绑定在功能feature而非组件component上与 Next.js App Router 下以页面为功能单元的架构是自洽的。4.2 集成测试的三步动作渲染页面或复杂模态框如AgentPublishModal通过 MSW 模拟 API 请求通过 Testing Library 断言 UI 场景。两条重要的写法偏好优先测 UI 表面而非直接测 hook如果use*.tshook 只是为某个页面/组件服务就去测那个页面/组件而不是加renderHook()测试只有当共享 hook 拥有无法通过 UI 干净触发的独立业务逻辑时才值得直接测 hook优先使用 Orval 生成的 mock使用src/app/api/__generated__/endpoints/*/*.msw.ts中生成的 MSW handler 与响应构造器而不是手写 API 响应对象或 mock 页面/组件的 hook。文档给出的完整示例如下原文未删减地保留// 示例测试页面渲染来自 API 的数据 import { server } from /mocks/mock-server; import { getDeleteV2DeleteStoreSubmissionMockHandler422 } from /app/api/__generated__/endpoints/store/store.msw; test(shows error when submission fails, async () { // 覆盖默认 handler使其返回错误状态码 server.use(getDeleteV2DeleteStoreSubmissionMockHandler422()); render(MarketplacePage /); await screen.findByText(Featured Agents); // ... 断言错误 UI });文档还特别提醒优先使用findBy...系列查询——它们会等待元素出现异步代码不会导致 flaky 测试而普通的getBy...不会等待找不到会立即报错。4.3 Vitest setupMSW 如何在全局生效集成测试的全局初始化在 vitest.setup.tsx 中它比文档描述的多出一些工程细节值得理解beforeAll(() { mockNextjsModules(); mockAuthRequest(); // 如需用户数据请在具体测试中 mock auth actions——默认发送 null user仅为避免 cookies() 调用 return server.listen({ onUnhandledRequest: error }); }); afterEach(() { cleanup(); server.resetHandlers(); }); afterAll(() server.close());三个关键设计server.listen({ onUnhandledRequest: error })未匹配的 API 请求会直接抛错而不是静默穿透。配合 Orval 生成的全覆盖 handler这保证了测试中每一个 API 调用都走的是显式 mock杜绝了意外打到真实后端的可能afterEach中server.resetHandlers()会把server.use(...)的临时覆盖如 422 错误 handler还原为默认 handler避免用例间相互污染mockAuthRequest()注释说明auth 请求默认返回 null user避免 Next.js 的cookies()调用在测试环境报错具体测试若需要登录态用户应在测试内自行 mock auth actions。此外该文件还 mock 了react的cacheReact 18.3 只在react-server导出条件下提供cacheVitest 未设置该条件shim 为恒等函数去重语义降级为不去重以及number-flow/react其 shadow DOM rAF 动画与 React 18 并发渲染器在 happy-dom 下的 cleanup 冲突替换为普通span输出格式化文本。这类为让第三方库在测试环境可运行而做的 shim是集成测试基础设施的重要组成部分。五、单元测试与视觉测试5.1 单元测试Vitest RTL用于测试隔离的组件与工具函数纯工具函数如lib/utils.ts组件在不同 props 下的渲染组件状态变化具有独立业务逻辑的共享 hook放置规则与被测文件同目录、同名加.test后缀Component.test.tsx与Component.tsx并列。文档示例// 示例测试组件正确渲染 render(AgentCard titleMy Agent /); expect(screen.getByText(My Agent)).toBeInTheDocument();5.2 Storybook 视觉测试面向设计系统、视觉外观与组件文档覆盖 AtomsButton、Input、Badge、MoleculesDialog、Card、视觉状态hover、disabled、loading与响应式布局。Story 文件与被测组件同目录Component.stories.tsx与Component.tsx并列。这与优先级矩阵中Atoms 仅 Storybook形成呼应——原子组件的回归保障由视觉 diff 承担不写行为测试。六、MSW Mocking 机制从 OpenAPI 到错误场景的全链路文档MSW Mocking一节的完整语义可以概括为三点Handler 自动生成API mock 由 MSWMock Service Worker承担handler 由 Orval 从 OpenAPI schema 自动生成默认行为所有客户端请求被拦截返回 200 faker 生成的数据错误场景覆盖特定测试使用生成的错误 handler来模拟非 2xx 状态。仓库中可以看到这条链路的每一环orval.config.ts 中输入是./src/app/api/openapi.json并经过transformers/fix-tags.mjs转换输出到./src/app/api/__generated__/endpointstags-split 模式与./__generated__/modelsschemamock 配置为{ type: msw, baseUrl: /api/proxy, generateEachHttpStatus: true, delay: 0 }——generateEachHttpStatus: true正是每个 endpoint 拥有各状态码 handler如getDeleteV2DeleteStoreSubmissionMockHandler422的配置来源delay: 0保证测试中无人为延迟mock-server.ts 仅三行setupServer(...mockHandlers)即 MSW 的 Node 端 server供 vitest.setup 全局调用mock-handlers.ts则是 Orval 生成 handler 的聚合入口运行时浏览器端拦截另有src/mocks/mock-browser.ts与mocks/index.ts与测试环境的 Node server 是同一套 handler 的两种宿主。文档给出的错误场景覆盖示例保留原文import { server } from /mocks/mock-server; import { getDeleteV2DeleteStoreSubmissionMockHandler422 } from /app/api/__generated__/endpoints/store/store.msw; test(shows error when deletion fails, async () { server.use(getDeleteV2DeleteStoreSubmissionMockHandler422()); render(MyComponent /); // ... 断言错误 UI });生成 handler 的位置固定在src/app/api/__generated__/endpoints/*/每个 endpoint 按状态码提供不同 handler。文档末尾还有一条边界约定Playwright 的浏览器端辅助代码放在src/playwright/而不是src/tests/——src/tests/专属于 Vitest 集成测试基础设施test-utils.tsx、vitest.setup.tsx等。七、文件组织规范测试基础设施的物理布局文档File Organization一节给出了前端测试的完整目录契约原文结构保留src/ ├── components/ │ └── atoms/ │ └── Button/ │ ├── Button.tsx │ ├── Button.test.tsx # 单元测试 │ └── Button.stories.tsx # 视觉测试 ├── app/ │ └── (platform)/ │ └── marketplace/ │ └── components/ │ └── MainMarketplacePage/ │ ├── __tests__/ │ │ ├── main.test.tsx # 集成测试 │ │ └── search-agents.test.tsx # 集成测试 │ ├── MainMarketplacePage.tsx │ └── useMainMarketplacePage.ts ├── lib/ │ ├── utils.ts │ └── utils.test.ts # 单元测试 ├── mocks/ │ ├── mock-handlers.ts # MSW handlersOrval 自动生成 │ └── mock-server.ts # MSW server 设置 ├── playwright/ │ ├── *.spec.ts # E2E 测试集中放置 │ ├── pages/ # Playwright Page Objects │ └── utils/ # Playwright 辅助/fixture └── tests/ ├── integrations/ │ ├── test-utils.tsx # 测试工具 │ └── vitest.setup.tsx # 集成测试 setup └── AGENTS.md # 测试指导文档可以观察到组织原则的一致性单元测试与 stories 严格 co-locate同名文件并列集成测试收拢在功能目录的__tests__下E2E 全局集中而src/tests/integrations/只放共享基础设施copilot-sse.ts、mock-auth-request.tsx、setup-nextjs-mocks.tsx、test-utils.tsx、vitest.setup.tsx。八、Golden Rules八条铁律速查文档最后以Golden Rules收尾这八条是整个体系的行为准则适合作为 code review 检查清单测行为不测实现—— 按 role/text 查询而不是 class 名一个概念一条断言—— 测试应聚焦在边界处 mock—— mock API 调用不 mock 内部函数集成测试就地存放——__tests__/目录紧贴组件E2E 很昂贵—— 只留给关键 happy path优先用集成测试AI agent 擅长写集成测试—— 新增测试覆盖时从集成测试开始优先组件/页面测试而非 hook 测试—— 不要为组件实现细节添加renderHook()覆盖使用生成的 API mock—— 优先 Orval MSW 辅助函数而非手写的 API 对象 stub。小结AutoGPT Platform 前端测试体系的本质是以功能为单位分层以 OpenAPI 为 mock 单一事实来源用决策树把每条用例归入 E2E/集成/单元/视觉中最便宜的层级用 Orval MSW 把 API 边界从手写 stub 变成 schema 驱动的生成物用onUnhandledRequest: error和resetHandlers保证 mock 的严密性与用例隔离再用 coverage-fixture 让 E2E 用例的 V8 覆盖率进入 Codecov 报告。对于在该仓库上开发前端功能的工程师而言先读 AGENTS.md 的决策矩阵与 Golden Rules再对照 vitest.setup.tsx 与 orval.config.ts 理解基础设施即可写出符合项目规范的测试。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AutoGPT 前端测试体系全解：E2E、集成测试、单元测试与 MSW 模拟的选型与落地实践
AutoGPT 前端测试体系全解E2E、集成测试、单元测试与 MSW 模拟的选型与落地实践【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPTAutoGPT Platform 前端采用 PlaywrightE2E Vitest/RTL集成与单元测试 Storybook视觉的三层测试体系并通过 Orval 从 OpenAPI 规范自动生成 MSW 模拟数据。本文基于仓库中 前端测试规则文档完整梳理各测试类型的适用场景、文件组织规范与 MSW 拦截机制并深入到 Vitest 配置、覆盖率 fixture、Mock 服务源码层帮助你在 AutoGPT 前端项目中正确地选择测试层级、写出可复现且不易 flaky 的测试。一、测试类型总览四层金字塔与工具选型官方文档 autogpt_platform/frontend/src/tests/AGENTS.md 首先给出了一张测试类型速查表这是整个前端测试体系的骨架类型工具速度用途E2EPlaywright慢约 5s/条真实浏览器完整用户旅程IntegrationVitest RTL快约 100ms组件 模拟 APIUnitVitest RTL最快约 10ms单个函数/组件VisualStorybook ChromaticN/AUI 外观、设计系统从仓库实际配置看这套体系是真实落地的而非纸面规范Vitest 侧的入口配置见 vitest.config.mts测试环境使用happy-dom用例匹配src/**/*.test.tsx、src/**/*.test.ts与scripts/**/*.test.ts全局 setup 指向./src/tests/integrations/vitest.setup.tsx覆盖率由 v8 provider 生成textcobertura两种报告输出到./coverage目录并显式排除了测试文件、stories 文件、src/playwright/**与src/tests/**自身保证覆盖率只统计业务代码E2E 侧的规格文件集中在src/playwright/目录下如auth-happy-path.spec.ts、builder-happy-path.spec.ts、marketplace-happy-path.spec.ts等与文档中E2E 数量少、集中放置的定位一致。二、选型决策流程这条测试该写在哪个层级文档给出了一个清晰的决策树判断顺序是是否需要真实浏览器/后端 → 是否涉及 API 或复杂状态 → 是否关乎视觉外观Does it need a REAL browser/backend? ├─ YES → E2E (Playwright) └─ NO └─ Does it involve API calls or complex state? ├─ YES → Integration (Vitest RTL) └─ NO └─ Is it about visual appearance? ├─ YES → Storybook └─ NO → Unit (Vitest RTL)与之配套的是优先级矩阵明确了不同组件类型应当投入的测试精力组件类型测试优先级推荐测试Pages/Features最高IntegrationCustom Hooks中父级集成测试或共享 hook 单元测试Utility Functions高UnitOrganisms复杂组件高IntegrationMolecules中Unit StorybookAtoms中仅 Storybook** Atoms 通常足够简单Storybook 视觉测试即可覆盖。同时文档明确列出了不该测的内容第三方库内部实现Radix UI、React Query、CSS 样式细节交给 Storybook、无逻辑的简单 prop 透传组件、TypeScript 类型本身。这些负向清单与正向矩阵结合可以显著避免测试债的膨胀。三、E2E 测试Playwright 集中化管理与覆盖率采集3.1 适用场景与放置位置E2E 只用于必须在真实浏览器中才能验证的关键用户旅程认证流程登录、注册、登出支付或敏感交易依赖真实浏览器 API 的流程剪贴板、下载必须端到端打通的跨页面导航所有 E2E 用例集中放在src/playwright/*.spec.ts原因很简单——E2E 数量少且昂贵Golden Rules 第 5 条明确E2E is expensive集中放置便于维护。仓库中可以看到按 happy path 划分的规格文件auth-happy-path.spec.ts、builder-happy-path.spec.ts、publish-happy-path.spec.ts 等另有pages/Page Object与utils/辅助 fixture子目录与文档中File Organization一节完全对应。3.2 覆盖率 fixture为什么不能直接 import playwright/test文档中一条硬性规则值得特别展开E2E 测试必须从./coverage-fixture导入test和expect而不是playwright/test// 正确 import { test, expect } from ./coverage-fixture; // 错误——会绕过覆盖率采集 import { test, expect } from playwright/test;其实现见 coverage-fixture.ts逻辑是基于playwright/test的base扩展出一个自动 fixtureautoTestFixture在每条用例scope: test, auto: true开始时调用page.coverage.startJSCoverage({ resetOnNavigation: false })开启 V8 覆盖率采集用例结束后stopJSCoverage()并用monocart-reporter的addCoverageReport将结果挂到test.info()上最终汇入 Codecov 报告。源码中有两处防御性细节startJSCoverage用 try/catch 包裹非浏览器场景下 coverage API 可能不可用teardown 阶段的失败也被静默吞掉注释写明不要让覆盖率收尾失败掩盖真实的测试失败。这意味着绕过该 fixture 的代价不是少跑一个断言而是整条用例的 V8 覆盖率数据从 Codecov 报告中消失。四、集成测试页面级优先、UI 行为优先4.1 放置位置与拆分策略集成测试用于测试带依赖的组件API 调用、状态管理放置在与组件同级的__tests__目录中ComponentName/ __tests__/ main.test.tsx some-flow.test.tsx ComponentName.tsx useComponentName.ts文档明确主张从页面级开始不必为每个小组件写集成测试而应该先测页面例如/library/ __tests__/ main.test.tsx searching-agents.test.tsx agents-pagination.test.tsx page.tsx useLibraryPage.ts策略是先建一个main.test.tsx随着用例增长再拆分为更小的文件。这个策略把测试粒度绑定在功能feature而非组件component上与 Next.js App Router 下以页面为功能单元的架构是自洽的。4.2 集成测试的三步动作渲染页面或复杂模态框如AgentPublishModal通过 MSW 模拟 API 请求通过 Testing Library 断言 UI 场景。两条重要的写法偏好优先测 UI 表面而非直接测 hook如果use*.tshook 只是为某个页面/组件服务就去测那个页面/组件而不是加renderHook()测试只有当共享 hook 拥有无法通过 UI 干净触发的独立业务逻辑时才值得直接测 hook优先使用 Orval 生成的 mock使用src/app/api/__generated__/endpoints/*/*.msw.ts中生成的 MSW handler 与响应构造器而不是手写 API 响应对象或 mock 页面/组件的 hook。文档给出的完整示例如下原文未删减地保留// 示例测试页面渲染来自 API 的数据 import { server } from /mocks/mock-server; import { getDeleteV2DeleteStoreSubmissionMockHandler422 } from /app/api/__generated__/endpoints/store/store.msw; test(shows error when submission fails, async () { // 覆盖默认 handler使其返回错误状态码 server.use(getDeleteV2DeleteStoreSubmissionMockHandler422()); render(MarketplacePage /); await screen.findByText(Featured Agents); // ... 断言错误 UI });文档还特别提醒优先使用findBy...系列查询——它们会等待元素出现异步代码不会导致 flaky 测试而普通的getBy...不会等待找不到会立即报错。4.3 Vitest setupMSW 如何在全局生效集成测试的全局初始化在 vitest.setup.tsx 中它比文档描述的多出一些工程细节值得理解beforeAll(() { mockNextjsModules(); mockAuthRequest(); // 如需用户数据请在具体测试中 mock auth actions——默认发送 null user仅为避免 cookies() 调用 return server.listen({ onUnhandledRequest: error }); }); afterEach(() { cleanup(); server.resetHandlers(); }); afterAll(() server.close());三个关键设计server.listen({ onUnhandledRequest: error })未匹配的 API 请求会直接抛错而不是静默穿透。配合 Orval 生成的全覆盖 handler这保证了测试中每一个 API 调用都走的是显式 mock杜绝了意外打到真实后端的可能afterEach中server.resetHandlers()会把server.use(...)的临时覆盖如 422 错误 handler还原为默认 handler避免用例间相互污染mockAuthRequest()注释说明auth 请求默认返回 null user避免 Next.js 的cookies()调用在测试环境报错具体测试若需要登录态用户应在测试内自行 mock auth actions。此外该文件还 mock 了react的cacheReact 18.3 只在react-server导出条件下提供cacheVitest 未设置该条件shim 为恒等函数去重语义降级为不去重以及number-flow/react其 shadow DOM rAF 动画与 React 18 并发渲染器在 happy-dom 下的 cleanup 冲突替换为普通span输出格式化文本。这类为让第三方库在测试环境可运行而做的 shim是集成测试基础设施的重要组成部分。五、单元测试与视觉测试5.1 单元测试Vitest RTL用于测试隔离的组件与工具函数纯工具函数如lib/utils.ts组件在不同 props 下的渲染组件状态变化具有独立业务逻辑的共享 hook放置规则与被测文件同目录、同名加.test后缀Component.test.tsx与Component.tsx并列。文档示例// 示例测试组件正确渲染 render(AgentCard titleMy Agent /); expect(screen.getByText(My Agent)).toBeInTheDocument();5.2 Storybook 视觉测试面向设计系统、视觉外观与组件文档覆盖 AtomsButton、Input、Badge、MoleculesDialog、Card、视觉状态hover、disabled、loading与响应式布局。Story 文件与被测组件同目录Component.stories.tsx与Component.tsx并列。这与优先级矩阵中Atoms 仅 Storybook形成呼应——原子组件的回归保障由视觉 diff 承担不写行为测试。六、MSW Mocking 机制从 OpenAPI 到错误场景的全链路文档MSW Mocking一节的完整语义可以概括为三点Handler 自动生成API mock 由 MSWMock Service Worker承担handler 由 Orval 从 OpenAPI schema 自动生成默认行为所有客户端请求被拦截返回 200 faker 生成的数据错误场景覆盖特定测试使用生成的错误 handler来模拟非 2xx 状态。仓库中可以看到这条链路的每一环orval.config.ts 中输入是./src/app/api/openapi.json并经过transformers/fix-tags.mjs转换输出到./src/app/api/__generated__/endpointstags-split 模式与./__generated__/modelsschemamock 配置为{ type: msw, baseUrl: /api/proxy, generateEachHttpStatus: true, delay: 0 }——generateEachHttpStatus: true正是每个 endpoint 拥有各状态码 handler如getDeleteV2DeleteStoreSubmissionMockHandler422的配置来源delay: 0保证测试中无人为延迟mock-server.ts 仅三行setupServer(...mockHandlers)即 MSW 的 Node 端 server供 vitest.setup 全局调用mock-handlers.ts则是 Orval 生成 handler 的聚合入口运行时浏览器端拦截另有src/mocks/mock-browser.ts与mocks/index.ts与测试环境的 Node server 是同一套 handler 的两种宿主。文档给出的错误场景覆盖示例保留原文import { server } from /mocks/mock-server; import { getDeleteV2DeleteStoreSubmissionMockHandler422 } from /app/api/__generated__/endpoints/store/store.msw; test(shows error when deletion fails, async () { server.use(getDeleteV2DeleteStoreSubmissionMockHandler422()); render(MyComponent /); // ... 断言错误 UI });生成 handler 的位置固定在src/app/api/__generated__/endpoints/*/每个 endpoint 按状态码提供不同 handler。文档末尾还有一条边界约定Playwright 的浏览器端辅助代码放在src/playwright/而不是src/tests/——src/tests/专属于 Vitest 集成测试基础设施test-utils.tsx、vitest.setup.tsx等。七、文件组织规范测试基础设施的物理布局文档File Organization一节给出了前端测试的完整目录契约原文结构保留src/ ├── components/ │ └── atoms/ │ └── Button/ │ ├── Button.tsx │ ├── Button.test.tsx # 单元测试 │ └── Button.stories.tsx # 视觉测试 ├── app/ │ └── (platform)/ │ └── marketplace/ │ └── components/ │ └── MainMarketplacePage/ │ ├── __tests__/ │ │ ├── main.test.tsx # 集成测试 │ │ └── search-agents.test.tsx # 集成测试 │ ├── MainMarketplacePage.tsx │ └── useMainMarketplacePage.ts ├── lib/ │ ├── utils.ts │ └── utils.test.ts # 单元测试 ├── mocks/ │ ├── mock-handlers.ts # MSW handlersOrval 自动生成 │ └── mock-server.ts # MSW server 设置 ├── playwright/ │ ├── *.spec.ts # E2E 测试集中放置 │ ├── pages/ # Playwright Page Objects │ └── utils/ # Playwright 辅助/fixture └── tests/ ├── integrations/ │ ├── test-utils.tsx # 测试工具 │ └── vitest.setup.tsx # 集成测试 setup └── AGENTS.md # 测试指导文档可以观察到组织原则的一致性单元测试与 stories 严格 co-locate同名文件并列集成测试收拢在功能目录的__tests__下E2E 全局集中而src/tests/integrations/只放共享基础设施copilot-sse.ts、mock-auth-request.tsx、setup-nextjs-mocks.tsx、test-utils.tsx、vitest.setup.tsx。八、Golden Rules八条铁律速查文档最后以Golden Rules收尾这八条是整个体系的行为准则适合作为 code review 检查清单测行为不测实现—— 按 role/text 查询而不是 class 名一个概念一条断言—— 测试应聚焦在边界处 mock—— mock API 调用不 mock 内部函数集成测试就地存放——__tests__/目录紧贴组件E2E 很昂贵—— 只留给关键 happy path优先用集成测试AI agent 擅长写集成测试—— 新增测试覆盖时从集成测试开始优先组件/页面测试而非 hook 测试—— 不要为组件实现细节添加renderHook()覆盖使用生成的 API mock—— 优先 Orval MSW 辅助函数而非手写的 API 对象 stub。小结AutoGPT Platform 前端测试体系的本质是以功能为单位分层以 OpenAPI 为 mock 单一事实来源用决策树把每条用例归入 E2E/集成/单元/视觉中最便宜的层级用 Orval MSW 把 API 边界从手写 stub 变成 schema 驱动的生成物用onUnhandledRequest: error和resetHandlers保证 mock 的严密性与用例隔离再用 coverage-fixture 让 E2E 用例的 V8 覆盖率进入 Codecov 报告。对于在该仓库上开发前端功能的工程师而言先读 AGENTS.md 的决策矩阵与 Golden Rules再对照 vitest.setup.tsx 与 orval.config.ts 理解基础设施即可写出符合项目规范的测试。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考