前端 Tests 写作
- 作者仓库星标 184,730
- 作者仓库 AutoGPT
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, 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 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:
- Is it a page? (
page.tsx) — these are the primary test targets - Is it a hook? (
use*.ts) — test via the page/component that uses it; avoid directrenderHook()tests unless it is a shared reusable hook with standalone business logic - Is it a component? (
.tsxincomponents/) — test via the parent page unless it's complex enough to warrant isolation - Is it a helper? (
helpers.ts,utils.ts) — unit test directly if pure logic
Priority order:
- Pages with new/changed data fetching or user interactions
- Components with complex internal logic (modals, forms, wizards)
- Shared hooks with standalone business logic when UI-level coverage is impractical
- 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(/my agents/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/reactdirectly) - Use
server.use()to set up MSW handlers BEFORE rendering - Use
findBy*(async) for elements that appear after data fetching — NOTgetBy* - Use
getBy*only for elements that are immediately present in the DOM - Use
screenqueries — do NOT destructure fromrender() - Use
waitForwhen asserting side effects or state changes after interactions - Import
fireEventoruserEventfrom 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 —renderandfireEventhandle 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:
- Read the error output carefully
- Fix the test (not the source code, unless there is a genuine bug)
- Re-run until all pass
Then run the full checks:
pnpm format
pnpm lint
pnpm types- 流狐分类
- AI 智能
- 作者声明 Agent
- 未找到明确声明;不据此推断已兼容或已测试
- 静态检查
- 88 / 100 · 启发式扫描,不代表运行安全
- 作者 / 版本 / 许可
- @Significant-Gravitas · 未声明 license
- 流狐 Token 估算
- 低消耗
- 流狐接入估算
- 即装即用
- 是否需要外部 API Key
- 未发现要求
- 检测到的系统要求
- 未声明
- 底层运行要求
- 未声明
- 检测到的文件与系统行为
-
- 只读
- 允许写入 / 修改
- 检测到的网络行为
- 允许外网请求
- 安装命令数
- 无(仅作为资料)
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
作者没有在当前 SKILL.md 中定义固定输出样例。 Also read the diff to understand what changed:
For each changed file, determine: Is it a page? (page.tsx) — these are the primary test targets 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…
For each test target, check if tests already exist: 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: For each API hook found, locate the corresponding MSW handler: 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: 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:
# 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
```bash
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:
```bash
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
… 作者原文负责流程事实;流狐只索引当前章节、要点、文件与命令。
章节 -> References → Step 1: Identify changed frontend files → Step 2: Categorize changes and find test targets → Step 3: Check for existing tests → Step 4: Identify API endpoints used → Step 5: Write the test plan
要点 -> Is it a page? · Is it a hook? · Is it a component? · Is it a helper? · Priority order
文件/命令 -> autogptplatform/frontend/TESTING.md · autogptplatform/frontend/src/tests/AGENTS.md · autogptplatform/frontend/src/tests/integrations/test-utils.tsx · autogptplatform/frontend/src/tests/integrations/vitest.setup.tsx · page.tsx · use.ts · renderHook() · .tsx
内容 SHA-256 -> bf11dcb458e0
方法与流程
适用与边界
原文中的明确线索
autogptplatform/frontend/TESTING.md、autogptplatform/frontend/src/tests/AGENTS.md、autogptplatform/frontend/src/tests/integrations/test-utils.tsx、autogptplatform/frontend/src/tests/integrations/vitest.setup.tsx、page.tsx、use.ts、renderHook()、.tsx