跳到正文
cccskills
免费在 GitHub 公开中文介绍

write-frontend-tests

根据当前分支的前端差异选择测试对象,确认计划后编写验证页面操作和API响应的集成测试,并执行测试、格式整理、代码检查及类型检查。

原文查看原文说明

Analyze the current branch diff against dev, plan integration tests for changed frontend pages/components, and write them. TRIGGER when user asks to write frontend tests, add test coverage, or 'write tests for my changes'.

实测评分 未实测

查看安装方法

适用场景

  • 为当前页面修改补充测试
  • 验证加载、错误和空数据状态
  • 测试表单和弹窗操作
  • 按行为变更更新已有测试

中文介绍

功能

比较当前分支与基础分支的差异,为修改过的前端页面和组件规划、编写集成测试。集成测试会结合页面显示、用户操作和数据获取进行验证。使用MSW模拟API响应,覆盖正常响应、加载中、错误和空数据等情况,也会判断已有测试需要补充还是更新。

适用场景

适合在修改页面的数据获取或交互后,梳理哪些位置需要增加测试。优先测试页面,也包括逻辑复杂的表单和弹窗。仅涉及外观、类型或配置的修改不列入测试对象。

使用示例

  • “为这个分支的前端修改补充测试。”
  • “查看与dev的差异,制定测试计划。”
  • “验证列表页面在出错和数据为空时的显示。”

注意事项

基础分支默认为dev。编写代码前会展示测试计划,并等待用户确认。流程以AutoGPT的前端结构、现有测试规范、专用渲染辅助工具和MSW配置为前提。使用pnpm执行测试,之后还会进行格式整理、代码检查和类型检查。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
A良好编码前等待计划确认,使用MSW模拟API,并列出执行的验证命令。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足需要专用渲染辅助工具、MSW配置和pnpm,但未提供安装配置步骤。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月23日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md7.3 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Write Frontend Tests

Analyze the current branch's frontend changes, plan integration tests, and write them.

References

Before writing any tests, read the testing rules and conventions:

  • autogpt_platform/frontend/TESTING.md — testing strategy, file locations, examples
  • autogpt_platform/frontend/src/tests/AGENTS.md — detailed testing rules, MSW patterns, decision flowchart
  • autogpt_platform/frontend/src/tests/integrations/test-utils.tsx — custom render with providers
  • autogpt_platform/frontend/src/tests/integrations/vitest.setup.tsx — MSW server setup

Step 1: Identify changed frontend files

BASE_BRANCH="${ARGUMENTS:-dev}"
cd autogpt_platform/frontend

# Get changed frontend files (excluding generated, config, and test files)
git diff "$BASE_BRANCH"...HEAD --name-only -- src/ \
  | grep -v '__generated__' \
  | grep -v '__tests__' \
  | grep -v '\.test\.' \
  | grep -v '\.stories\.' \
  | grep -v '\.spec\.'

Also read the diff to understand what changed:

git diff "$BASE_BRANCH"...HEAD --stat -- src/
git diff "$BASE_BRANCH"...HEAD -- src/ | head -500

Step 2: Categorize changes and find test targets

For each changed file, determine:

  1. Is it a page? (page.tsx) — these are the primary test targets
  2. Is it a hook? (use*.ts) — test via the page/component that uses it; avoid direct renderHook() tests unless it is a shared reusable hook with standalone business logic
  3. Is it a component? (.tsx in components/) — test via the parent page unless it's complex enough to warrant isolation
  4. Is it a helper? (helpers.ts, utils.ts) — unit test directly if pure logic

Priority order:

  1. Pages with new/changed data fetching or user interactions
  2. Components with complex internal logic (modals, forms, wizards)
  3. Shared hooks with standalone business logic when UI-level coverage is impractical
  4. Pure helper functions

Skip: styling-only changes, type-only changes, config changes.

Step 3: Check for existing tests

For each test target, check if tests already exist:

# For a page at src/app/(platform)/library/page.tsx
ls src/app/\(platform\)/library/__tests__/ 2>/dev/null

# For a component at src/app/(platform)/library/components/AgentCard/AgentCard.tsx
ls src/app/\(platform\)/library/components/AgentCard/__tests__/ 2>/dev/null

Note which targets have no tests (need new files) vs which have tests that need updating.

Step 4: Identify API endpoints used

For each test target, find which API hooks are used:

# Find generated API hook imports in the changed files
grep -rn 'from.*__generated__/endpoints' src/app/\(platform\)/library/
grep -rn 'use[A-Z].*V[12]' src/app/\(platform\)/library/

For each API hook found, locate the corresponding MSW handler:

# If the page uses useGetV2ListLibraryAgents, find its MSW handlers
grep -rn 'getGetV2ListLibraryAgents.*Handler' src/app/api/__generated__/endpoints/library/library.msw.ts

List every MSW handler you will need (200 for happy path, 4xx for error paths).

Step 5: Write the test plan

Before writing code, output a plan as a numbered list:

Test plan for [branch name]:

1. src/app/(platform)/library/__tests__/main.test.tsx (NEW)
   - Renders page with agent list (MSW 200)
   - Shows loading state
   - Shows error state (MSW 422)
   - Handles empty agent list

2. src/app/(platform)/library/__tests__/search.test.tsx (NEW)
   - Filters agents by search query
   - Shows no results message
   - Clears search

3. src/app/(platform)/library/components/AgentCard/__tests__/AgentCard.test.tsx (UPDATE)
   - Add test for new "duplicate" action

Present this plan to the user. Wait for confirmation before proceeding. If the user has feedback, adjust the plan.

Step 6: Write the tests

For each test file in the plan, follow these conventions:

File structure

import { render, screen, waitFor } from "@/tests/integrations/test-utils";
import { server } from "@/mocks/mock-server";
// Import MSW handlers for endpoints the page uses
import {
  getGetV2ListLibraryAgentsMockHandler200,
  getGetV2ListLibraryAgentsMockHandler422,
} from "@/app/api/__generated__/endpoints/library/library.msw";
// Import the component under test
import LibraryPage from "../page";

describe("LibraryPage", () => {
  test("renders agent list from API", async () => {
    server.use(getGetV2ListLibraryAgentsMockHandler200());

    render(<LibraryPage />);

    expect(await screen.findByText(/all workflows/i)).toBeDefined();
  });

  test("shows error state on API failure", async () => {
    server.use(getGetV2ListLibraryAgentsMockHandler422());

    render(<LibraryPage />);

    expect(await screen.findByText(/error/i)).toBeDefined();
  });
});

Rules

  • Use render() from @/tests/integrations/test-utils (NOT from @testing-library/react directly)
  • Use server.use() to set up MSW handlers BEFORE rendering
  • Use findBy* (async) for elements that appear after data fetching — NOT getBy*
  • Use getBy* only for elements that are immediately present in the DOM
  • Use screen queries — do NOT destructure from render()
  • Use waitFor when asserting side effects or state changes after interactions
  • Import fireEvent or userEvent from the test-utils for interactions
  • Do NOT mock internal hooks or functions — mock at the API boundary via MSW
  • Prefer Orval-generated MSW handlers and response builders over hand-built API response objects
  • Do NOT use act() manually — render and fireEvent handle it
  • Keep tests focused: one behavior per test
  • Use descriptive test names that read like sentences

Test location

# For pages: __tests__/ next to page.tsx
src/app/(platform)/library/__tests__/main.test.tsx

# For complex standalone components: __tests__/ inside component folder
src/app/(platform)/library/components/AgentCard/__tests__/AgentCard.test.tsx

# For pure helpers: co-located .test.ts
src/app/(platform)/library/helpers.test.ts

Custom MSW overrides

When the auto-generated faker data is not enough, override with specific data:

import { http, HttpResponse } from "msw";

server.use(
  http.get("http://localhost:3000/api/proxy/api/v2/library/agents", () => {
    return HttpResponse.json({
      agents: [{ id: "1", name: "Test Agent", description: "A test agent" }],
      pagination: { total_items: 1, total_pages: 1, page: 1, page_size: 10 },
    });
  }),
);

Use the proxy URL pattern: http://localhost:3000/api/proxy/api/v{version}/{path} — this matches the MSW base URL configured in orval.config.ts.

Step 7: Run and verify

After writing all tests:

cd autogpt_platform/frontend
pnpm test:unit --reporter=verbose

If tests fail:

  1. Read the error output carefully
  2. Fix the test (not the source code, unless there is a genuine bug)
  3. Re-run until all pass

Then run the full checks:

pnpm format
pnpm lint
pnpm types

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

open-pr

免费有简介

检查代码变更的测试情况及对现有功能的影响,按仓库模板创建PR,并继续处理评审请求、反馈意见和CI检查。

  • 按指定模板创建PR
  • 检查现有功能与新功能的测试
  • 本地验证受限时请求机器人评审
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

orchestrate

免费有简介

在独立工作目录中运行多个Claude Code,统一分配开发任务、监控进度、协助恢复停止的会话,并检查PR测试及评审反馈的处理情况。

  • 向多个代理分配开发任务
  • 查看进度及空闲worktree
  • 恢复停止工作的代理
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

perf-compare

免费有简介

利用Sentry测量数据比较变更前后或不同环境的速度与失败率,考虑统计波动,判定加速、减速、未检测到变化或数据不足,并输出比较结果。

  • 比较发布前后的性能
  • 验证预览环境与对照环境
  • 检查其他操作是否变慢
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

pr-address

免费有简介

收集PR审查意见,推进代码修改、提交、回复及讨论串解决,同时持续检查CI失败、合并冲突和新增评论,跟进直至审查事项处理完成。

  • 修改PR审查指出的问题
  • 回复人工和机器人审查
  • 调查并修复推送后的CI失败
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

pr-polish

免费有简介

反复审查和修复PR,检查未解决的讨论、评论回复、自动检查及合并冲突,并等待延迟到达的评论,将PR整理到可以合并的状态。

  • 将PR整理到可合并状态
  • 反复修复直到没有新问题
  • 处理延迟到达的机器人审查
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

pr-review

免费有简介

审查拉取请求的目的和代码差异,检查正确性、安全性、设计及测试,避免重复已有评论,并将标注严重程度的问题发布到对应代码行。

  • 合并前审查拉取请求
  • 检查代码变更的安全性
  • 查找边界情况的测试缺口
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

查看 Significant-Gravitas 的全部技能

报告此技能的问题