本文へ移動
cccskills
無料GitHub で公開日本語紹介

write-frontend-tests

現在のブランチのフロントエンド差分からテスト対象を選び、計画の確認後に画面操作や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'.

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 現在の画面変更にテストを足したいとき
  • 読み込み中・エラー・空表示の検証
  • フォームやモーダルの操作テスト
  • 変更した動作に合わせた既存テスト更新

日本語での紹介

できること

現在のブランチと基点ブランチの差分を調べ、変更した画面や部品の結合テストを計画・作成します。結合テストは、画面表示や操作、データ取得を組み合わせて確認するものです。API応答を模擬するMSWを使い、正常時、読み込み中、エラー、データが空の場合などを検証します。既存テストの追加・更新も判断します。

こんなときに便利

画面のデータ取得や操作を変更した後、どこにテストを足すべきか整理したいときに向いています。ページを優先し、複雑なフォームやモーダルも対象にします。見た目だけ、型だけ、設定だけの変更は対象から外します。

使い方の例

  • 「このブランチのフロントエンド変更にテストを追加して」
  • 「devとの差分を見て、テスト計画を作って」
  • 「一覧画面のエラー時と空データ時の表示を検証して」

注意点

基点ブランチの既定値はdevです。コード作成前にテスト計画を提示し、利用者の確認を待つ手順です。AutoGPTのフロントエンド構成と既存のテスト規約、専用の描画補助、MSW設定を前提とします。実行にはpnpmを使い、テスト後に整形、lint、型チェックも行います。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

資料チェック

SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。

安全面送信・削除・コマンド実行などの扱いが明示されているか
A良好コード作成前に計画の確認を待ち、APIはMSWで模擬し、実行する検証コマンドも明示しています。
導入のしやすさ必要なツールや API キーが少ないか、書かれているか
B一部不足専用の描画補助・MSW設定・pnpmを使いますが、それらの導入手順はありません。

点数には入れていません。 2026年10月23日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。

評価が違うと思ったら、見直しを依頼する

どの項目が、なぜ違うと思うかを書いてください。ログインは不要です。内容を SKILL.md と照らし合わせて評価を作り直し、この欄に反映します。

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

含まれるファイル(1)

  • SKILL.md7.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

open-pr

無料概要あり

コード変更のテストと既存機能への影響を確認し、リポジトリ所定のテンプレートでPRを作成して、レビュー依頼から指摘への対応まで進めるスキル。

  • 所定のテンプレートでPRを作りたいとき
  • 既存動作と新機能のテストを確認する
  • ローカル検証が難しくbotに依頼する
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

orchestrate

無料概要あり

複数のClaude Codeを別々の作業フォルダで動かし、タスクの割り当て、進捗監視、停止時の再開支援、PRの完了確認をまとめて管理するスキル。

  • 複数エージェントへ開発を分担したいとき
  • 進捗と空きworktreeを確認したいとき
  • 停止したエージェントを再開したいとき
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

perf-compare

無料概要あり

Sentryの計測データで変更前後や環境間の速度と失敗率を比較し、統計的なばらつきを考慮して高速化・低速化・変化を検出できず・データ不足を判定するスキル。

  • リリース前後の性能比較
  • プレビュー環境と比較用環境の検証
  • ほかの処理の性能劣化を確認したいとき
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

pr-address

無料概要あり

PRのレビュー指摘を集め、コード修正・コミット・返信・解決処理を進めながら、CIの失敗や競合、新たなコメントも継続して確認し、対応完了まで追うスキル。

  • PRのレビュー指摘を修正したいとき
  • 人やボットのレビューへの返信
  • push後のCI失敗の調査と修正
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

pr-polish

無料概要あり

PRのレビューと修正対応を繰り返し、未解決の指摘やCIの失敗、競合を確認します。遅れて届くコメントも待ち受け、マージできる状態まで仕上げるスキル。

  • PRをマージ可能な状態に整えたいとき
  • 新しい指摘がなくなるまで修正したいとき
  • 遅れて届くボットレビューへの対応
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

pr-review

無料概要あり

プルリクエストの目的と差分を読み、正しさ・安全性・設計・テストを点検します。既存コメントとの重複を避け、重要度付きの指摘を該当行に投稿するスキル。

  • マージ前にPRを点検したいとき
  • 変更内容の安全性を確認したいとき
  • 境界条件のテスト不足を探したいとき
Significant-Gravitas/AutoGPT18.8万2026年10月23日 更新

Significant-Gravitas のスキルをすべて見る

このスキルの問題を報告する