ui-test-webdriverio について
WebdriverIOのUIテストを計画するプロンプト主体のスキルです。WebdriverIOを利用中、または導入予定のチーム向けに、プロジェクト情報から実行可能でリスクを重視したテスト計画を作成し、前提や不足情報も示します。
主な機能
- 01WebdriverIOテスト計画
- 02バージョン互換の非同期テスト
- 03ワーカーとセッションの分離
- 04障害と環境の診断
- 05CIへのエラー伝播
活用シーン
- 01WebdriverIOプロジェクトのUIテスト計画
- 02ブラウザーとドライバーの互換性確認
- 03分離された並列テストセッションの設計
- 04設定エラーと製品不具合の切り分け
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ naodeng/ awesome-qa-skills --skill ui-test-webdriverioインストール後、Claude Code で/ui-test-webdriverioを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
README.mdagents/openai.yamlevals/eval.yamlevals/cases/basic-success.yamldomain-method-regression.yamledge-incomplete-input.yamledge-scope-boundary.yamlevals/fixtures/check_domain_decisions.pycheck-domain-decisions.shdomain-oracle.jsonevals/fixtures/checkout-app/checkout.spec.cjsindex.htmlREADME.mdreceipt.htmlserver.mjswdio.conf.cjsexamples/sample-context.mdoutput-templates/template-markdown.mdprompts/ui-test-webdriverio.mdreferences/domain-decision-example.mdframework-spec.mdsetup-and-ci.mdscripts/run-tests.sh詳細
WebdriverIO UI Testing(EN)
中国語版: 対応する中国語のスキルをご覧ください。
使用する場面
- WebdriverIO の UI テストワークフローにそのまま組み込める出力が必要な場合。
- プロジェクトですでに WebdriverIO を使用している場合、または WebdriverIO に対応した計画が必要な場合。
出力形式の選択肢
リクエストで別の形式が明示されていない限り、Markdown がデフォルトです。
使用方法
prompts/ui-test-webdriverio.mdを開き、メインプロンプトとして使用します。- 範囲、環境、制約、リスク、依存関係、期待する成果物など、実際のプロジェクトのコンテキストを追加します。
- 入力が不完全な場合は、実用的な初版を提示し、不足している情報と前提を明記します。
参考ファイル
-
ドメイン上の結果、有効な制御方法、または証拠の不足を評価する際は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算について、references/domain-decision-example.md をお読みください。
-
prompts/ui-test-webdriverio.md:このスキルのメインプロンプトです。 -
references/framework-spec.md:ツール固有の構成とカバレッジに関する注意事項です。 -
references/setup-and-ci.md:セットアップ、実行、CI に関する注意事項です。 -
examples/sample-context.md:リクエストコンテキストの例です。 -
scripts/run-tests.sh:ローカルで軽量に実行するためのエントリーポイントです。
ドメイン実行に関する重要事項
- WebdriverIO/Node、ランナー/フレームワーク、ブラウザー/ドライバー/サービスの組み合わせを固定します。capability/service がインストール済みのパッケージ、設定、リモート対応状況と適合するか確認します。名前だけでは互換性を証明できません。
- バージョンに対応した async の spec/BDD ステップを生成し、すべての async コマンドを await します。観測可能なビジネス条件または要素の条件を待機し、コマンドエラーを捕捉して成功扱いにしてはいけません。
- セットアップ/クリーンアップフックを使って、ワーカーごとにセッション、ID、ビジネスキーを分離します。指定されたプラットフォーム/ブラウザーのマトリックスのみを対象とし、範囲が指定されていない場合は不明のままにします。
- テスト/ワーカー/セッション/capability の ID、バージョン、URL、スクリーンショット/ログ、元のスタックを保持します。CONFIG_ERROR、ビジネスアサーションの失敗、環境エラーを区別し、診断情報と CI への伝播を含めます。
よくある落とし穴
- 範囲が曖昧で、コンテキストがない場合は使用しないでください。
- すべての領域を同じ重要度として扱わないでください。
- 前提や不足している情報を省略しないでください。
ベストプラクティス
-
プロンプトファイルから始め、重要なコンテキストだけを追加します。
-
リスクに基づいた、実行可能な出力にします。
-
リクエストが不完全な場合は、実用的な初版を提示し、不足事項を明記します。
-
生成されたビジネスアサーション、失敗の伝播、または分離を検証するには、evals/fixtures/checkout-app/README.md とローカルの good/bug/timeout 制御をお読みください。実行するのは、実行がリクエストされた場合に限ります。