write-frontend-tests
- Repo stars 184,730
- Author updated Live
- Author repo AutoGPT
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @Significant-Gravitas · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: write-frontend-tests
description: Analyze the current branch diff against dev, plan integration tests for changed frontend pages/c…
category: ai
runtime: no special runtime
---
# write-frontend-tests output preview
## PART A: Task fit
- Use case: 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'..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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'.”.
- **02** When the source has headings, the agent prioritizes “References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: write-frontend-tests
description: Analyze the current branch diff against dev, plan integration tests for changed frontend pages/c…
category: ai
source: Significant-Gravitas/AutoGPT
---
# write-frontend-tests
## When to use
- Analyze the current branch diff against dev, plan integration tests for changed frontend pages/components, and write t…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "write-frontend-tests" {
input -> user goal + target files + boundaries + acceptance criteria
context -> References / Step 1: Identify changed frontend files / Step 2: Categorize changes and find test targets
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 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
Decide Fit First
Design Intent
How To Use It
Boundaries And Review