Agent Skills by ALSEL
Anthropic Claudeソフトウェア開発⭐ リポ 0品質スコア 50/100

frontend-testing-best-practices

フロントエンドのテストにおけるベストプラクティスを提供します。ユニットテストよりもE2Eテストを重視し、モックを最小限に抑え、実装の詳細ではなく動作をテストすることを推奨します。テストの作成やテストコードのレビュー時に使用してください。

description の原文を見る

Testing best practices for the frontend. Emphasizes E2E tests over unit tests, minimal mocking, and testing behavior over implementation details. Use when writing tests or reviewing test code.

SKILL.md 本文

テスト ベストプラクティス

実際の信頼性を提供する効果的で保守しやすいテストを書くためのガイドラインです。E2E テストの優先、モッキングの最小化、実装ではなく動作のテストに焦点を当てた6つのルールを含みます。

基本的な考え方

  1. ユニットテストより E2E テストを優先する - 独立した部品ではなく、システム全体をテストする
  2. モッキングを最小化する - 複雑なモックが必要な場合は、E2E テストを書く
  3. 実装ではなく動作をテストする - ユーザーが見て実行することをテストする
  4. React コンポーネントを直接テストしない - E2E を通じてテストする

適用タイミング

以下の場合にこのガイドラインを参照してください:

  • どのタイプのテストを書くか決定する時
  • 新しい E2E またはユニットテストを書く時
  • テストコードをレビューする時
  • テストをリファクタリングする時

ルール概要

テスト戦略 (重要)

prefer-e2e-tests - @rules/prefer-e2e-tests.md

デフォルトで E2E テストを使用します。純粋な関数に対してのみユニットテストを書いてください。

// E2E テスト (推奨) - 実際のユーザーフローをテスト
test("user can place an order", async ({ page }) => {
  await createTestingAccount(page, { account_status: "active" });
  await page.goto("/catalog");
  await page.getByRole("heading", { name: "Example Item" }).click();
  await page.getByRole("link", { name: "Buy" }).click();
  // ... 完全なフロー
  await expect(page.getByAltText("Thank you")).toBeVisible();
});

// ユニットテスト - 純粋な関数のみ
test("formatCurrency formats with two decimals", () => {
  expect(formatCurrency(1234.5)).toBe("$1,234.50");
});

avoid-component-tests - @rules/avoid-component-tests.md

React コンポーネントをユニットテストしないでください。E2E またはテストしないでください。

// 悪い例: コンポーネントのユニットテスト
describe("OrderCard", () => {
  test("renders amount", () => {
    render(<OrderCard amount={100} />);
    expect(screen.getByText("$100")).toBeInTheDocument();
  });
});

// 良い例: E2E テストがコンポーネントを自然にカバーする
test("order history shows orders", async ({ page }) => {
  await page.goto("/orders");
  await expect(page.getByText("$100")).toBeVisible();
});

minimize-mocking - @rules/minimize-mocking.md

モックはシンプルに保ってください。3 個以上のモックが必要な場合は、E2E テストを書いてください。

// 悪い例: モックが多すぎる = E2E テストを書く
vi.mock("~/lib/auth");
vi.mock("~/lib/transactions");
vi.mock("~/hooks/useAccount");

// 良い例: ローダーテストのシンプルな MSW モック
mockServer.use(
  http.get("/api/user", () => HttpResponse.json({ name: "John" })),
);

E2E テスト (高)

e2e-test-structure - @rules/e2e-test-structure.md

E2E テストは frontend/ ではなく e2e/tests/ に配置してください。

// e2e/tests/order.spec.ts
import { test, expect } from "@playwright/test";
import { addAccountBalance, createTestingAccount } from "./utils";

test.describe("Orders", () => {
  test.beforeEach(async ({ page, context }) => {
    await createTestingAccount(page, { account_status: "active" });
    let cookies = await context.cookies();
    let account_id = cookies.find((c) => c.name === "account_id").value;
    await addAccountBalance({ account_id, amount: 10000, replaceBalance: true });
  });

  test("place order with default values", async ({ page }) => {
    await page.goto("/catalog");
    // ... ユーザーフロー
  });
});

e2e-selectors - @rules/e2e-selectors.md

アクセシブルなセレクターを使用してください: role > label > text > testid。

// 良い例: ロールベース (推奨)
await page.getByRole("button", { name: "Submit" }).click();
await page.getByRole("heading", { name: "Dashboard" });

// 良い例: ラベルベース
await page.getByLabel("Email").fill("test@example.com");

// OK: アクセシブルなセレクターが存在しない場合は Test ID
await expect(page.getByTestId("balance")).toHaveText("$1,234");

// 悪い例: CSS セレクター
await page.locator(".btn-primary").click();

ユニットテスト (中)

unit-test-structure - @rules/unit-test-structure.md

ユニットテストは純粋な関数のみです。ソースファイルと同じ場所に配置してください。

// app/utils/format.test.ts
import { describe, test, expect } from "vitest";
import { formatCurrency } from "./format";

describe("formatCurrency", () => {
  test("formats positive amounts", () => {
    expect(formatCurrency(1234.5)).toBe("$1,234.50");
  });

  test("handles zero", () => {
    expect(formatCurrency(0)).toBe("$0.00");
  });
});

キーファイル

  • e2e/tests/ - E2E テスト (Playwright)
  • e2e/tests/utils.ts - E2E テストユーティリティ
  • vitest.config.ts - ユニットテスト設定
  • vitest.setup.ts - MSW を使用したグローバルテスト設定
  • app/utils/test-utils.ts - ユニットテストユーティリティ

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
sergiodxa
リポジトリ
sergiodxa/agent-skills
ライセンス
MIT
最終更新
不明

Source: https://github.com/sergiodxa/agent-skills / ライセンス: MIT

関連スキル

汎用ソフトウェア開発⭐ リポ 39,967

doubt-driven-development

重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 1,175

apprun-skills

TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。

by yysun
OpenAIソフトウェア開発⭐ リポ 797

desloppify

コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。

by Git-on-my-level
汎用ソフトウェア開発⭐ リポ 39,967

debugging-and-error-recovery

テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

test-driven-development

テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

incremental-implementation

変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。

by addyosmani
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: sergiodxa · sergiodxa/agent-skills · ライセンス: MIT