platform-testing

原則

• 実装の詳細ではなく、振る舞いをテストします
• 単体テストよりも統合テストを優先します（Testing Trophy）
• すべてのテストで Arrange-Act-Assert（AAA）パターンを使用します
• テストは互いに独立させます。変更可能な状態を共有してはいけません
• テストは小さく、焦点を絞ります。1つのテストにつき1つの振る舞いを検証します
• 検証する振る舞いがわかるテスト名を付けます
• カバレッジ率ではなく、信頼性を高めることを優先します
• カバレッジ100％を追求せず、重要な項目をテストします

ルール

詳しいパターンについては、ルールの索引を参照してください。

例

発動する例

ユーザー：「統合テストと単体テストの境界、およびモックの方針を定義してください。」

期待される動作：platform-testing のガイダンスを使用し、そのワークフローに従って、実行可能な内容を返します。

発動しない例

ユーザー：「課金処理用の tRPC ルーターを作成してください。」

期待される動作：platform-testing を優先せず、より関連性の高いスキルを選ぶか、スキルを使わずに対応します。

トラブルシューティング

スキルが発動しない

• エラー：想定したスキルが選択されません。
• 原因：リクエストの表現が、説明にある発動条件に明確に一致していません。
• 解決策：説明にある分野やタスクのキーワードを明示して言い換え、もう一度試します。

ガイダンスが別のスキルと競合する

• エラー：複数のスキルの指示が、1つのタスクで競合します。
• 原因：読み込まれたスキルの対象範囲が重複しています。
• 解決策：現在のステップでどのスキルを優先するかを指定し、そのワークフローを先に適用します。

出力が抽象的すぎる

• エラー：結果に具体的で実行可能な詳細がありません。
• 原因：タスクの入力に、コンテキスト、制約、または目標とする形式が不足しています。
• 解決策：具体的な制約（環境、範囲、形式、成功基準）を追加して、もう一度実行します。

ワークフロー

1. リクエストが platform-testing の対象範囲や発動条件に明確に一致するかを確認します。
2. スキルのルールと参照先のガイダンスを適用し、具体的な結果を作成します。
3. 制約に照らして出力の品質を検証します。不足があれば、明示的な前提を加えて一度だけ改善します。