mcpField
F
frontend-review-testing

frontend-review-testing

github.com/mizchi测试与质量41646 次安装1 周前更新
代码仓库

关于 frontend-review-testing

供团队评估现有项目测试状况的前端测试审计技能。它检查配置、覆盖率、测试结构和缺口，并提出优先处理事项；不会编写测试或运行测试套件。

主要功能

  1. 01审计测试与覆盖率配置
  2. 02检查 Vitest 和 Playwright 设置
  3. 03识别测试缺口并提议 PR
  4. 04建议验证可观察行为的组件测试
  5. 05评估覆盖率与分支测试需求
  6. 06记录测试失败分诊指引

适用场景

  1. 01评估前端项目的测试现状
  2. 02规划路由器和控制器的初始 E2E 测试
  3. 03发现组件测试实践中的缺口

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mizchi/skills --skill frontend-review-testing

安装后在 Claude Code 中输入/frontend-review-testing确认已加载。

附带文件README.md

详细介绍

前端评审——测试

你正在审查一个前端项目的测试状况。当前阶段为第 2 周：建立 vitest + playwright，并采用合成覆盖率，同时注意：

  • E2E 粒度：初期，Router / 服务端控制器的每个分支各编写一个用例（先搭建骨架，不追求穷尽）。
  • 单元测试粒度：优先覆盖组件。
  • 覆盖率合并：使用 monocart-coverage-reports 或 istanbul-merge 合并 vitest V8 + playwright V8 覆盖率。

流程

  1. 运行 scripts/audit-coverage.sh --repo <client-repo>。
  2. 如果存在 coverage/coverage-summary.json，阅读该文件。
  3. 检查：
    • vitest.config.*——是否配置了覆盖率？使用的是 v8 提供程序吗？
    • playwright.config.*——projects、webServer、分片配置
    • tests/、e2e/、__tests__/——当前测试数量和结构
    • package.json 脚本——test、test:coverage、test:e2e

输出

写入 <client-repo>/.frontend-review/report/latest/md/testing-review.md，包含：

  • 当前状态：是否配置了 vitest？是否配置了 playwright？有多少项测试？覆盖率是多少？
  • 差距：缺失的配置、缺失的脚本、未合并覆盖率
  • 建议的 PR（最多 3-5 项）：每项列出标题、涉及文件、预期覆盖率增幅
  • 分支覆盖清单：应优先编写 E2E 测试的 Router / 控制器分支

组件测试——优先使用 Testing Library

对于 React 组件测试，优先使用 @testing-library/react，而不是测试内部实现：

  • 按角色 / 标签 / 文本查询（getByRole、getByLabelText、getByText），而不是按类名或组件内部结构查询。
  • 用户交互通过 @testing-library/user-event 实现——使用 userEvent.click、userEvent.type，而不是直接分发 DOM 事件。
  • 异步断言使用 waitFor / findBy*，检查异步操作后的状态更新。
// Bad: testing implementation details
const wrapper = render(<LoginForm />);
wrapper.find('button.submit').simulate('click');
expect(wrapper.state('isLoading')).toBe(true);

// Good: testing observable behaviour
render(<LoginForm />);
await userEvent.type(screen.getByLabelText('Email'), '[email protected]');
await userEvent.click(screen.getByRole('button', { name: /sign in/i }));
expect(await screen.findByText('Welcome')).toBeInTheDocument();

如果 package.json 中没有 @testing-library/react，请将其标记为差距，并建议同时添加 @testing-library/user-event 和 @testing-library/jest-dom（或 @testing-library/vitest-dom）。

对于 atom / store 测试，使用该库自己的测试工具（例如 Jotai createStore()），而不是渲染组件——将组件测试与状态逻辑测试分开。

源码内测试模式

对于逻辑密集的 .ts 文件，通常更适合将测试与源代码放在同一文件中（Vite 项目使用 if (import.meta.vitest)，或使用等效的构建时死代码剔除方式），而不是单独创建测试文件：

  • AI Agent 可以在同一文件上下文中读取源代码和规范，从而提高生成准确性。
  • 纯函数与其不变量保持紧密关联。
  • 生产构建通过 "import.meta.vitest": "undefined" define 剔除测试代码块。

为工具 / lib 文件提出新的单元测试时，建议采用此模式。

测试失败分诊流程

测试失败时，正确的做法不是机械地重写测试以使其通过。应让人类决定：

  1. 规范已变更——当前实现正确；更新测试。
  2. 实现存在错误——测试正确；修复实现。
  3. 测试有误——测试从未符合预期规范；重写测试。

在输出报告中记录此分诊流程。将任何看起来像“实现回声”（测试的是确切的内部路径，而非可观察行为）的现有测试标记为第 3 类候选项。

MSW（Mock Service Worker）原则

当代码库会从外部 API 获取数据时，建议使用 MSW，而不是 jest 风格的模块模拟：

  • 仅在网络边界模拟（http.get、http.post 处理器）。
  • 保留实际的状态管理 / 组件连接，仅替换 HTTP 响应。
  • 将共享处理器放在 src/test-utils/handlers.ts 或等效位置。

这样可以避免出现集成契约已失效、测试却仍然通过的情况。

覆盖率指导

  • 目标：纯 lib/utility 文件达到 80% 以上；UI 组件达到 60% 以上。
  • 反面目标：不要为了达到 100% 而堆砌测试。优先编写数量较少、能体现真实规范的测试，而不是大量枚举实现细节的测试。
  • 生成的 UI 组件（例如 shadcn/ui 的输出）不纳入覆盖率要求。

VRT 稳定性提示

  • 在 Linux 容器中生成参考快照（与 CI 使用相同的操作系统），以消除不同机器之间的字体渲染和抗锯齿差异。
  • 通过共享 fixture 全局注入 Web 字体，而不是在每个测试中单独注入——字体不可用会导致像素差异比较出现误报。

边界

  • 不要编写实际测试代码——只提出结构和数量。
  • 不要通过此 skill 运行 vitest 或 playwright；这些脚本不会执行测试，只会读取现有报告。

参考

  • 检查清单：07-unit-test.md、08-e2e-playwright.md、15-vrt.md、13-kpi-tracking.md
  • 阶段：week-2-testing.md、week-3-security-vrt.md

评论

支持 Markdown