检查代码变更的测试情况及对现有功能的影响,按仓库模板创建PR,并继续处理评审请求、反馈意见和CI检查。
- 按指定模板创建PR
- 检查现有功能与新功能的测试
- 本地验证受限时请求机器人评审
根据当前分支的前端差异选择测试对象,确认计划后编写验证页面操作和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 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。
不计入评分。 由 AI(OpenAI Codex)于 2026年10月23日 评估。仅供参考,安装前请同时查看原文。
安装前可以查看交给 AI 代理的指令内容。
Analyze the current branch's frontend changes, plan integration tests, and write them.
Before writing any tests, read the testing rules and conventions:
autogpt_platform/frontend/TESTING.md — testing strategy, file locations, examplesautogpt_platform/frontend/src/tests/AGENTS.md — detailed testing rules, MSW patterns, decision flowchartautogpt_platform/frontend/src/tests/integrations/test-utils.tsx — custom render with providersautogpt_platform/frontend/src/tests/integrations/vitest.setup.tsx — MSW server setupBASE_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
For each changed file, determine:
page.tsx) — these are the primary test targetsuse*.ts) — test via the page/component that uses it; avoid direct renderHook() tests unless it is a shared reusable hook with standalone business logic.tsx in components/) — test via the parent page unless it's complex enough to warrant isolationhelpers.ts, utils.ts) — unit test directly if pure logicPriority order:
Skip: styling-only changes, type-only changes, config changes.
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.
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).
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.
For each test file in the plan, follow these conventions:
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();
});
});
render() from @/tests/integrations/test-utils (NOT from @testing-library/react directly)server.use() to set up MSW handlers BEFORE renderingfindBy* (async) for elements that appear after data fetching — NOT getBy*getBy* only for elements that are immediately present in the DOMscreen queries — do NOT destructure from render()waitFor when asserting side effects or state changes after interactionsfireEvent or userEvent from the test-utils for interactionsact() manually — render and fireEvent handle it# 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
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.
After writing all tests:
cd autogpt_platform/frontend
pnpm test:unit --reporter=verbose
If tests fail:
Then run the full checks:
pnpm format
pnpm lint
pnpm types
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
检查代码变更的测试情况及对现有功能的影响,按仓库模板创建PR,并继续处理评审请求、反馈意见和CI检查。
在独立工作目录中运行多个Claude Code,统一分配开发任务、监控进度、协助恢复停止的会话,并检查PR测试及评审反馈的处理情况。
利用Sentry测量数据比较变更前后或不同环境的速度与失败率,考虑统计波动,判定加速、减速、未检测到变化或数据不足,并输出比较结果。
收集PR审查意见,推进代码修改、提交、回复及讨论串解决,同时持续检查CI失败、合并冲突和新增评论,跟进直至审查事项处理完成。
反复审查和修复PR,检查未解决的讨论、评论回复、自动检查及合并冲突,并等待延迟到达的评论,将PR整理到可以合并的状态。
审查拉取请求的目的和代码差异,检查正确性、安全性、设计及测试,避免重复已有评论,并将标注严重程度的问题发布到对应代码行。