Skip to content
cccskills
FreePublished on GitHubEnglish overview

write-frontend-tests

Review frontend changes against a base branch, propose a test plan, and write integration tests that check pages and components together. Cover user interactions and API responses, then run tests, formatting, lint, and type checks.

OriginalShow the original description

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

Run score Not tested

See how to install

Good for

  • Add tests for frontend changes on the current branch
  • Check loading, error, and empty states
  • Test interactions in forms and modals
  • Extend existing tests to cover changed behavior

Overview

What it does

Compares the current branch with a base branch to plan and write integration tests for changed frontend pages and components. These tests check screen content, interactions, and data fetching together. It uses MSW to simulate API responses and verify successful responses, loading states, errors, and empty data. It also determines whether existing tests need additions or updates.

When it helps

Use it after changing how a screen fetches data or responds to user actions, when you need to identify where tests belong. Pages take priority, while complex forms and modals are also included. Changes limited to appearance, types, or configuration are excluded.

Example requests

  • “Add tests for this branch’s frontend changes.”
  • “Compare this branch with dev and prepare a test plan.”
  • “Test the list page’s error and empty-data displays.”

Notes

The default base branch is dev. It presents a test plan and waits for your confirmation before writing code. It assumes AutoGPT’s frontend structure, existing testing conventions, custom rendering helper, and MSW configuration. It uses pnpm to run tests, followed by formatting, lint, and type checks.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Document check

AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).

SafetyAre sending data, deleting files, and running commands disclosed?
AGoodIt waits for plan confirmation before coding, simulates APIs with MSW, and lists the verification commands it runs.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingIt requires a custom rendering helper, MSW configuration, and pnpm, but provides no instructions for setting them up.

Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 23, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

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

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

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

open-pr

FreeSummary

Create a pull request that follows the project's template and title conventions. Check existing behavior and test coverage, document testing limits, and coordinate self-review or bot review with follow-up on reported issues.

  • Create a PR using the project's required template
  • Check regression tests and coverage for new behavior
  • Request bot review when local testing is limited
Significant-Gravitas/AutoGPT187.7KUpdated Oct 23, 2026

orchestrate

FreeSummary

Coordinate multiple Claude Code agents in separate Git worktrees and tmux windows. Assign tasks, inspect progress, help stalled agents resume, and verify PR checks and review feedback before treating work as complete.

  • Assign separate development tasks to multiple agents
  • Check agent progress and available worktrees
  • Help stalled or crashed agent sessions resume
Significant-Gravitas/AutoGPT187.7KUpdated Oct 23, 2026

perf-compare

FreeSummary

Compare performance across releases, environments, or time windows using Sentry data. Report request counts, latency percentiles, and failure rates, with statistical checks that distinguish faster or slower behavior from noise and flag insufficient data.

  • Compare performance before and after a release
  • Compare a preview deployment with a control
  • Check other operations for performance regressions
Significant-Gravitas/AutoGPT187.7KUpdated Oct 23, 2026

pr-address

FreeSummary

Work through PR review feedback by fixing code, pushing commits, replying to reviewers, and resolving addressed threads. Monitor automated checks, merge conflicts, and new comments until checks pass and the review work is complete.

  • Fix code based on PR review feedback
  • Reply to human and bot reviewers
  • Investigate failed CI checks after a push
Significant-Gravitas/AutoGPT187.7KUpdated Oct 23, 2026

pr-polish

FreeSummary

Prepare a pull request for merging by repeatedly reviewing changes and addressing feedback. Verify resolved discussions, passing automated checks, and mergeability, then check twice for late comments after the checks finish.

  • Preparing a pull request for merging
  • Repeating review and fixes until no new issues remain
  • Following up on delayed review bot feedback
Significant-Gravitas/AutoGPT187.7KUpdated Oct 23, 2026

pr-review

FreeSummary

Review a pull request, a proposed code change, for correctness, security, design, and test coverage. Check its explanation and existing feedback, then post findings on relevant code lines with severity labels.

  • Checking a pull request before merging
  • Reviewing security risks in code changes
  • Finding missing edge-case tests
Significant-Gravitas/AutoGPT187.7KUpdated Oct 23, 2026

See all skills by Significant-Gravitas

Report a problem with this skill