mcpField
W
wp-test-strategy

wp-test-strategy

github.com/jorgerosalテスト・品質11173 回インストール20 週間前に更新
リポジトリ

wp-test-strategy について

wp-test-strategy は、WordPress のプラグインやテーマ向けのテスト計画を支援します。変更リスクと対象範囲に応じて、ユニットテストから E2E テストまで適切な深さを検討できます。

主な機能

  1. 01リスクに応じたテスト深度の選定
  2. 02ユニット・統合・E2E テストの選択
  3. 03REST、ブロック、WooCommerce の網羅性確認
  4. 04rg によるテストと不足箇所の検索
  5. 05優先度に沿ったテスト提案

活用シーン

  1. 01機能や修正のテスト計画
  2. 02プラグインやテーマの網羅性不足の確認
  3. 03リリース前の回帰テスト計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jorgerosal/wordpress-skills --skill wp-test-strategy

インストール後、Claude Code で/wp-test-strategyを入力して読み込まれたか確認します。

同梱ファイルreferences/test-layer-guide.mdreferences/wordpress-test-scenarios.md

詳細

WordPress テスト戦略スキル

概要

WordPress プロジェクト向けの体系的なテスト戦略ガイダンスです。基本原則: テストの深さはリスクに応じたものとし、テストピラミッドには対象となる WordPress の領域を反映させる必要があります。レビューでは、ユニットテスト、WordPress 統合テスト、REST エンドポイントテスト、ブロックテスト、ブラウザーテストまたは E2E テスト、WooCommerce のリグレッション、フィクスチャ、リリースリスクの優先順位付けを対象とします。

使用する場面

次の場合に使用します:

  • 機能や修正に追加するテストを決める場合
  • プラグインやテーマで不足しているカバレッジをレビューする場合
  • リリース前のリグレッションテストを計画する場合
  • ユニット、統合、E2E のどのカバレッジを選ぶか判断する場合
  • ブロック、REST、管理画面、WooCommerce の動作をテストに対応付ける場合

次の場合には使用しないでください:

  • テストに関する判断を含まないコードレビュー
  • CI システムのデバッグのみ
  • パフォーマンスのベンチマークのみ

コードレビューワークフロー

  1. 変更の対象領域を特定する

    • PHP のみのロジック
    • WordPress との統合動作
    • REST または AJAX のフロー
    • ブロックエディターの動作
    • 管理画面のワークフロー
    • WooCommerce の注文/カート/チェックアウトの動作
  2. リスクを評価する

    • ユーザー向け機能の破損
    • データ破損または移行のリスク
    • 認証/セキュリティに関わるフロー
    • ブラウザー操作の複雑さ
  3. テストの深さを選ぶ

    • 分離されたロジックにはユニットテスト
    • WordPress API と DB の状態には統合テスト
    • UI ワークフローやエディターの操作には E2E テスト
  4. 推奨事項を報告する

    • テストすべき内容
    • 適切なテストレベル
    • 省略できる内容、または間接的にカバーできる内容

テスト選択のヒューリスティクス

ユニットテスト

次の場合に使用します:

  • 純粋な変換ロジック
  • 小規模なヘルパー
  • 書式設定および解析ロジック
  • WP ランタイムから切り離された検証ルール
統合テスト

次の場合に使用します:

  • フックとフィルター
  • オプション/メタデータの永続化
  • REST エンドポイント
  • カスタムクエリー
  • ロール/権限の動作
E2E テストまたはブラウザーテスト

次の場合に使用します:

  • ブロックエディターのフロー
  • JS の動作を伴う管理画面フォーム
  • チェックアウト、カート、フロントエンドの操作
  • アクセシビリティに配慮が必要な操作フロー

迅速な検出のための検索パターン(TST-21)

以下の rg コマンドを使って、現在のテストカバレッジと不足している可能性のある箇所を把握します。

カバレッジの調査
# Test directories and files
rg -n "class .*Test|extends .*TestCase|describe\\(|test\\(" . -g '*.{php,js,jsx,ts,tsx}'

# PHPUnit config or bootstrap
rg -n "phpunit|tests/bootstrap|WP_UnitTestCase" .

# Playwright or E2E indicators
rg -n "playwright|@wordpress/e2e-test-utils|page\.goto|test\\(" . -g '*.{js,ts}'
不足を示すシグナル
# High-risk surfaces with no obvious tests nearby
rg -n "register_rest_route|add_action|add_filter|wp_ajax_|admin_post_|dbDelta|WC_" . -g '*.php'

# Block editor files
rg -n "block.json|edit\\(|save\\(|registerBlockType" . -g '*.{json,js,jsx}'

参照ファイル

  • references/test-layer-guide.md - WordPress プロジェクトでユニット、統合、E2E のどのカバレッジを選ぶか
  • references/wordpress-test-scenarios.md - プラグイン、ブロック、テーマ、REST API、WooCommerce に推奨されるテストシナリオ

出力形式(TST-23)

報告する際は、次の項目に沿って整理します:

  1. レビュー対象の領域
  2. 推奨するテストの種類
  3. 優先度が最も高い未カバー項目
  4. あると望ましいカバレッジ

既存のテストで十分な場合は、その旨を明確に伝え、残存リスクや未カバーのエッジケースがあれば記載します。

コメント