Skip to content
cccskills
FreePublished on GitHub

write-frontend-tests

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'.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md7.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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(/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/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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Review code for quality, bugs, and improvements. Use when user wants code review or quality assessment.

The English summary is being prepared. Showing the original description.

HIDORAKAI002/ai-workspace-archive37Updated Oct 21, 2026

Analyze datasets and extract insights. Use when user needs to understand data patterns, statistics, or trends.

The English summary is being prepared. Showing the original description.

HIDORAKAI002/ai-workspace-archive37Updated Oct 21, 2026

Incrementally update Mintlify documentation (.mdx) from Python source changes only. Use when: (1) Python files referenced in doc_code_map frontmatter have changed, (2) a PR touches Python modules documented in docs/mintlify/key_modules/ or docs/mintlify/mcp/, (3) the user asks to sync docs after Python code changes. Prefer minimal diffs and leave correct content untouched.

The English summary is being prepared. Showing the original description.

HIDORAKAI002/ai-workspace-archive37Updated Oct 21, 2026

Open a pull request with proper PR template, test coverage, and review workflow. Guides agents through creating a PR that follows repo conventions, ensures existing behaviors aren't broken, covers new behaviors with tests, and handles review via bot when local testing isn't possible. TRIGGER when user asks to "open a PR", "create a PR", "make a PR", "submit a PR", "open pull request", "push and create PR", or any variation of opening/submitting a pull request.

The English summary is being prepared. Showing the original description.

HIDORAKAI002/ai-workspace-archive37Updated Oct 21, 2026

Meta-agent supervisor that manages a fleet of Claude Code agents running in tmux windows. Auto-discovers spare worktrees, spawns agents, monitors state, kicks idle agents, approves safe confirmations, and recycles worktrees when done. TRIGGER when user asks to supervise agents, run parallel tasks, manage worktrees, check agent status, or orchestrate parallel work.

The English summary is being prepared. Showing the original description.

HIDORAKAI002/ai-workspace-archive37Updated Oct 21, 2026

Address PR review comments and loop until CI green and all comments resolved. TRIGGER when user asks to address comments, fix PR feedback, respond to reviewers, or babysit/monitor a PR.

The English summary is being prepared. Showing the original description.

HIDORAKAI002/ai-workspace-archive37Updated Oct 21, 2026

See all skills by HIDORAKAI002

Report a problem with this skill