テスト(プロフェッショナル)

スキルテキストは日本語で提供されます。

各ランナーの公式ドキュメントを使用してください(例：Jest、Vitest、Playwright、pytest)；このスキルはテスト戦略、CI フィードバック設計、障害モード、自動化衛生をエンコードします — フレームワークチュートリアルの重複ではありません。このリポジトリの*-proスキルを使用するコードベースの場合、言語/ランナー、CI 環境、およびどの統合フレームワークスキルが適用されるかを確認してください。

範囲

testing-proはどのレイヤーで何をテストするか、決定論性、不安定性ポリシー、CI ステージとアーティファクト、および横断的な RTL/クエリ優先順位を担当します。react-pro / nextjs-pro / nestjs-pro / … はランナー設定、API、およびスタック固有のハーネス詳細を担当します。ci-cd-proは主要トピックとしてパイプライン YAMLを担当します；テストジョブ設計とシグナルについてはここで組み合わせてください。

関連スキル(このリポジトリ)

スキル	testing-proと組み合わせる場合
react-pro	RTL/Vitest/Jest セットアップ、コンポーネントテスト、フック
nextjs-pro	App Router、RSC/"use client"テスト境界、サーバー vs クライアント
nestjs-pro	TestingModule、Supertest E2E、プロバイダーモック
flutter-pro	widget_test、integration_test、ゴールデンファイル
react-native-pro	Detox/Maestro、RN Jest 設定
postgresql-pro	実際の SQL に対する統合テスト、RLS、マイグレーション
security-pro	悪用ケースとリグレッション セキュリティテスト
ci-cd-pro	ワークフロー配線、キャッシング、マトリックス、シークレット — テスト意図はここに留まります

それらのスキルに属するフレームワーク固有のテストアドバイスを重複させないでください；リンクし、ここで横断的なテスト設計を追加してください。

使用する場合

• テストスイートの設計またはリファクタリング(レイヤー、命名、フォルダレイアウト)。
• 自動化：CI ワークフロー、並列ジョブ、レポート、アーティファクト、再試行ポリシー。
• ツールの選択(ランナー vs E2E vs ブラウザ vs API vs ロード)。
• 不安定なテストのデバッグ、タイムアウト、非同期レース、または環境ドリフト。
• カバレッジのレビューとそれが証明しないもの。

使用しない場合

• 主なトピックがテスト戦略なしの CI/CD プラットフォーム YAML — **ci-cd-pro**から始めます、テストレイアウト用にこのスキルを組み合わせます。
• テストの視点のない純粋なアプリケーションバグ — 関連の**stack-proまたはgitnexus-debugging**スタイルのワークフローを使用します。
• エンジニアリングテスト証拠を超えた法律/コンプライアンス証明。

必須入力

• スタック(言語、ランナー、ブラウザランナー(該当する場合))。
• CI ターゲット(PR vs main、シャーディング、利用可能なサービス)。

期待される出力

**推奨応答形式(厳密)**に従います — コンテキストから残存リスクまで。

ワークフロー

Karpathy の原則を全体に適用します：コーディング前に考える、シンプル優先、確実な変更、目標駆動実行。

1. スタック、CI、および関連スキルテーブルから適用可能なフレームワークスキル**を確認します。→ 検証：[コンテキストがドキュメント化されている]。
2. 前提条件を述べます，制約(コーディング前に考える)について。
3. 最小限のソリューションを適用；正当化されるときのみエスカレーション(シンプル優先)。
4. 確実な変更を加える — リクエストに直接関連するコード、テスト、フィクスチャ、モック、自動化配線のみに対応(確実な変更)。
5. 成功基準を定義；検証されるまでループ(目標駆動実行)。
6. 推奨応答形式を使用して応答；主なリスクを記述します。

運用原則

1. コーディング前に考える — テストを変更する前に、製品サーフェス、ランナー、および CI 制約を確認します。目標が信頼性、速度、またはバグ再現かが不明な場合は質問します。
2. シンプル優先 — 動作を証明できる最も安価なテストレイヤーから始めます。単体またはエネティクステストで十分な場合は、E2E に飛び込まないでください。
3. 確実な変更 — リクエストされた動作に直接必要なテスト、フィクスチャ、モック、および自動化配線のみを追加または編集します。無関係なスイートは再記述しないでください。
4. 目標駆動実行 — 完了 = ターゲット動作が意図された環境で再現可能に検証され、テストシグナルが CI に対して十分に安定している。
5. ユーザーが観察可能な動作を最初にテスト — プライベート実装の詳細よりも、出力、DOM、API レスポンス、または状態遷移についてのアサーションを優先します。
6. 決定論性よりも巧妙さ — 再試行または隔離を追加する前に、時間、ランダム性、ネットワーク、およびシードデータを明示的に制御します。
7. 証拠はカバレッジシアターに勝る — カバレッジは探索を導くことができますが、リスクが閉じられていることを証明することはできません。
8. 不安定性は欠陥 — 不安定なテストは壊れた製品フィードバック；再試行を正常化する代わりにレース、環境ドリフト、または不正なセレクタを識別します。

シナリオ別のデフォルト推奨事項

• バグ修正 — 最初に最も狭い失敗テストでバグを再現し、次に本番コードにパッチを当て、次にテストが一貫して通過することを確認します。
• 新機能 — 最も低い有効レイヤーで 1 つの主要パステストを追加してから、統合境界またはユーザー重要フロー用のみ高いレイヤーカバレッジを追加します。
• リファクタ — 既存の高シグナルテストを保持；動作が不明またはリスクが集中している場合のみ特性テストを追加します。
• CI スローダウン — アサーションを削減する前に、高速な決定論的チェックをより遅い統合/E2E ジョブから分割します。

デシジョンツリー

概要：動作を証明できる最も低いテストレイヤーを選択し、統合境界、ブラウザ/デバイス動作、または本番配線が重要な場合のみエスケーレートします。

詳細：references/decision-tree.md

アンチパターン

概要：脆いスナップショット、実装詳細アサーション、根本原因なしで不安定なテストを再試行、および検証すると主張するレイヤーをモック。

詳細：references/anti-patterns.md

テストピラミッド、CI、フィードバックループ(概要)

単位、統合、E2E、およびパイプラインステージがどのように連携して、障害がノイジーではなくアクション可能になるか。

詳細：references/testing-pyramid-ci-and-feedback-system-model.md

障害モードと軽減(概要)

不安定性、環境ドリフト、セレクタの脆さ、偽の信頼の一般的な原因、および初期段階で検出する方法。

詳細：references/failure-modes-detection-mitigation.md

決定フレームワークとトレードオフ(概要)

モック時期、実際の依存関係をヒットする時期、および CI 時間に対して信頼性をトレードする方法。

詳細：references/decision-framework-and-trade-offs.md

自動化と CI(概要)

シャード、ゲート、アーティファクト公開、テスト障害が CI でデバッグ可能になる方法。

詳細：references/automation-and-ci.md

バージョン(概要)

サポートされた API または推奨セットアップを変更するランナーおよびエコシステムバージョン注記。

詳細：references/versions.md

推奨応答形式(厳密 — 実装/レビュー)

1. コンテキスト — スタック、ランナー、CI ターゲット、およびどのフレームワークスキルが製品固有のハーネスを所有するか。
2. テスト目標 — バグ再現、リグレッション防止、信頼性向上、または CI 安定化。
3. 推奨レイヤー — 単体、統合、E2E、コントラクト、ロード、またはビジュアル；これが最小限の十分なレイヤーである理由を説明します。
4. 実装 — テストケース、フィクスチャ、モック、および正確なアサーション；スニペット用にコードを使用します。
5. 検証 — 実行するコマンドまたは CI ジョブ、および通過証拠がどのようなものであるか。
6. 残存リスク — 残りの盲点、不安定性ベクトル、または環境差。

このスキルのリソース

トピック	ファイル
テストピラミッド、CI、フィードバックモデル	references/testing-pyramid-ci-and-feedback-system-model.md
テストピラミッドと戦略	references/test-pyramid-and-strategy.md
自動化と CI	references/automation-and-ci.md
障害モードと軽減	references/failure-modes-detection-mitigation.md
決定フレームワークとトレードオフ	references/decision-framework-and-trade-offs.md
デシジョンツリー	references/decision-tree.md
アンチパターン	references/anti-patterns.md
ヒントとコツ	references/tips-and-tricks.md
エッジケース	references/edge-cases.md
品質検証とガードレール	references/quality-validation-and-guardrails.md
統合マップ	references/integration-map.md
バージョン注記	references/versions.md

クイック例

入力： "チェックアウトバグが修正されました；リグレッションカバレッジが急速に必要です。"

• 最初に失敗するパスを再現する最も狭い統合またはコンポーネントテストを追加します。
• フィクスチャを最小限に保ち、内部メソッド呼び出しではなくユーザーが見える結果をアサートします。
• 検証： ターゲットテストはローカルで通過し、以前はバグを逃していた同じ CI ジョブで通過します。

入力(トリッキー)： "Playwright スイートは CI で真夜中の周りだけ不安定です。"

• 再試行を追加する前に、タイムゾーン、時計、またはシードデータドリフトを疑います。
• 時間またはシードデータを明示的に凍結；スクリーンショット、トレース、および CI アーティファクト内のタイムゾーン設定をキャプチャします。
• 検証： 同じシャードを CI で複数回再実行、点在した障害なし。

入力(横断的)： "Postgres RLS を備えた NestJS エンドポイント用テストが必要です。"

• **nestjs-proをTestingModuleとリクエスト配線用に、postgresql-pro**をアプリロールとテナントポリシーセットアップ用に組み合わせます。
• 認可境界をモック化する代わりに、実際のデータベースロール に対する統合テストを使用します。
• 検証： 許可されたテナントは通過、禁止されたテナントは失敗、ポリシー動作は本番ロールセマンティクスと一致します。

スキル完了前のチェックリスト

• テストを提案する前にスタック、ランナー、CI ターゲット確認(コーディング前に考える)
• 最小限の有効なテストレイヤーから開始；不必要な E2E 拡張なし(シンプル優先)
• リクエストされた動作に直接関連するテスト、フィクスチャ、自動化のみに対応(確実な変更)
• 成功基準と検証コマンドが明示的；ターゲット動作が意図された環境で証明済み(目標駆動実行)
• アサーションはプライベート実装詳細ではなく観察可能な動作に焦点
• 時間、ランダム性、ネットワーク、テストデータが決定論性が重要な場所で制御
• 再試行、隔離、またはスナップショット使用は不安定性を隠すのではなく正当化
• 残存する盲点または環境ギャップは明示的に述べられている