ln-42-acceptance-test-builder

受け入れテストビルダー

目標： 明示された要件について、ユーザーまたは外部システムから観測できる境界を通じて、信頼できる最小限の受け入れテスト群を提供します。承認されたテストとテストドキュメントのみを変更し、プロダクトコードを修正せず、正当な追加、更新、統合、削除を実施します。

実行上の契約： 順序付きのチェックボックスが完了の定義です。各項目を内部で PENDING、具体的な証拠がある PROVEN、条件が存在しないことを示す証拠がある CLEARED、または未解決事項がある UNPROVEN として管理します。読み取り、委任、ツールの失敗は証拠にはなりません。各セクションの後に項目を見直してください。回答を返す前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数えます。すべての未解決事項に対し、このスキルの判定および承認ルールを適用してください。 ユーザーの意図、スコープ、既存の承認を維持します。承認済みの作業は続行し、重大な未解決の選択肢や必要な外部承認がある場合に限って質問します。重大なリスクに応じて検証の深さを調整し、確認を暗黙に省略しないでください。依存関係と安全性の順序を守り、それ以外の場合は各要件に適した検証方法を選択してください。

ツールの使い分け

必要事項	推奨ツール	使用する場面	代替手段
ワークスペースの安全性	Git のステータス、差分、リポジトリの指示、ブランチまたはワークツリーの確認	編集の前に必ず実施	ユーザーの変更を安全に切り分けられない場合は中止
既存のテスト規約	ファイル一覧、検索、マニフェスト、ランナー設定、CI、対象を絞った読み取り	プロジェクトに適したランナー、配置、フィクスチャ、コマンドの選定	最も近い保守対象のテストパターンに従う
振る舞いと接続	言語サーバーまたはホストネイティブのコードインテリジェンス	観測可能なエントリーポイント、登録、利用箇所、状態境界の特定	範囲を絞った検索と直接確認
テストの実装	ネイティブの編集ツールとプロジェクトのジェネレーター	テスト、フィクスチャ、ヘルパー、必要最小限のテストドキュメントの作成	プロジェクトの慣例に沿った最小限のファイルのみを作成し、生成された状態を手作業で編集しない
観測可能な実行	リポジトリで定義されたシェルコマンド、ブラウザー、API クライアント、CLI、使い捨て可能な統合環境	UI、プロトコル、コマンド、または永続状態の結果を証明する	正確に不足している確認事項を示して INCOMPLETE を返す
外部契約	バージョンが一致する公式ドキュメントまたは仕様	期待される振る舞いが、最新の外部 API または標準に依存する場合	UNVERIFIED として記録し、推測した判定基準を記述しない

本番環境や、承認されていない外部ターゲットに対して受け入れテストを実行してはいけません。テストを通すことだけを目的に、デプロイ、公開、共有データの移行、認証情報のローテーションを行ったり、変更後の出力を受け入れたりしてはいけません。

エビデンスのルール

• 要件、公開された契約、例、不変条件、または独立した参照情報から期待される動作を導き出します。テスト対象の実装内の計算を根拠にしてはいけません。
• 中間ステータス、モック呼び出し、ログ行、内部メソッドの戻り値よりも、最終的に確定する結果やユーザーに見える結果を優先します。
• ゴールデンファイルやスナップショットは、決定的でレビュー可能な契約に限って使用します。期待出力の更新は仕様の変更であり、テストによる検証ではありません。
• セットアップ、データの割り当て、実行、クリーンアップ、再実行の動作を再現可能にします。再試行やクリーンアップによって最初の失敗が見えなくなる前に、その失敗を記録します。
• コマンドが成功しても、実証されるのは実際に実行された環境とシナリオだけです。対象外の各項目と利用できない境界をすべて明示します。
• 言語、フレームワーク、パッケージ、データベースベンダーなどに共通する一般的な動作はテストしません。それらに依存する、リポジトリが所有する観測可能な契約、構成、統合、ポリシーだけをテストします。
• KEEP、ADD、UPDATE、MERGE、DELETE、NO_TEST は、実行結果とは別のテスト資産の方針決定として扱います。既存のエビデンス、統合、廃止、または許容された残存リスクのほうが適切な場合に、安易に ADD を選んではいけません。
• テストの根拠が古くなっている場合、または必要な独自の動作、失敗モード、オラクルの強度、有用な失敗箇所の特定がすべて引き続きカバーされていることをエビデンスが示す場合に限り、削除または統合します。

チェックリスト

1. 変更範囲を確定する

• 要件、受け入れ条件、アクター、保護対象の結果、観測可能な契約、明示された対象外事項、承認済みのテスト資産方針、許可されたテストパス、許可されたテスト文書のパスを確認します。経験則から推測した品質は前提として明記します。
• 編集前に、適用されるリポジトリの指示を読み、Git の状態、未追跡ファイル、生成物の領域、既存のユーザー変更を確認します。
• プロジェクト標準のランナー、ディレクトリ構成、命名規則、フィクスチャ、セットアップ、クリーンアップ、環境設定、CI の実行方法を特定します。
• 新しいテストを作成する前に、要件または契約に影響される既存のテストを洗い出し、実際のオラクルを対応付けます。
• 各要件を、それを実証できる境界（UI、API、CLI、メッセージ、統合、ファイル、永続状態）に対応付けます。
• シナリオに必要な認証情報、サービス、アカウント、ポート、デバイス、ブラウザー、データセット、破壊的な影響を特定します。
• 安全な対象、信頼できる期待契約、または分離可能なワークスペースがない場合は、編集前に BLOCKED を返します。

2. 再現可能な受け入れエビデンスを設計する

• 各要件について、保護対象の結果、不具合クラス、セットアップ、アクション、最終結果、独立した判定基準、期待されるエビデンス、クリーンアップを定義します。
• 影響を受ける各テストと重大なリスクについて、ポートフォリオ内のアクションを1つ確認または導出します。承認済みの戦略がない場合は、影響、起こり得る障害、独自性、信頼性、保守コストに基づいてアクションを正当化します。既存の証明、別の制御策、または受容済みの残存リスクを記録したうえで、NO_TEST を記録します。
• 重大なユーザー可視のビジネスリスクに対しては、決定論的なエンドツーエンドのエビデンスを優先します。より狭い本番環境に即したコントラクトまたは統合境界を使うのは、それによって最終結果をより決定論的または正確に証明できる場合に限ります。受け入れエビデンスをユニット実装チェックで置き換えたり、観測可能なコントラクトに含まれない内部の詳細を対象にしたりしてはなりません。
• 無効な入力、認可、境界値、部分的な失敗、再試行、冪等性、復旧、互換性の振る舞いは、保護対象の結果に重大な影響を及ぼす可能性がある場合にのみ含めます。
• テストデータは一意または名前空間を分けて割り当て、再現性に影響する場合は、時刻、乱数、ロケール、順序、並行性を制御します。
• モックが受け入れ対象の振る舞いを迂回してしまう場合は、実際の依存関係または承認済みのエミュレーターを使用します。バージョンを固定し、準備完了状態とリセット動作を確認します。
• 決定論的な出力には、独立したコントラクトからゴールデンまたは差分の期待値を導出し、レビューしやすい小さな成果物に保ちます。
• 非決定論的な出力には、失敗を見えなくする正規化やノイズのスナップショットではなく、安定した不変条件と意味的なフィールドを検証します。
• 観測可能なコントラクトとロケール戦略に従って、安定したプロジェクト標準のセマンティックロケーター（ロール、アクセシブル名、ラベル）または明示的な ID／テストフックを使用します。スタイル、位置、タイミング、偶発的な構造には依存しないでください。コピーの完全一致が要件である場合は、それを個別に検証します。堅牢なセマンティックロケーターがある場合、フックを追加するためだけに製品コードの変更を求めてはなりません。
• エビデンスが一時的、互換性に依存、インシデント固有、または変化するコントラクトと結び付いている場合は、必須または診断用のゲートと、レビューまたは廃止のトリガーを定義します。

3. テストのスコープ内で実装する

• 既存のプロジェクト構成に従い、振る舞いを表す名前と、違反された要件、保護対象の結果、検出された不具合を特定できる失敗メッセージを使ってテストを作成または更新します。
• 承認済みの MERGE および DELETE アクションを実装し、置き換えられたテスト、フィクスチャ、スナップショット、ヘルパー、登録、CI エントリーを残さないようにします。置き換えの追跡可能性は、リポジトリー標準のパス、名前、タグ、またはタスクエビデンスで維持します。
• 保守されているフィクスチャとヘルパーは、デフォルト値と副作用を把握できる場合にのみ再利用します。1つのシナリオだけのために新しい抽象化を追加しないでください。
• 必要な前提条件がない場合はセットアップを速やかに失敗させ、成功、アサーション失敗、タイムアウト、キャンセル、部分的なセットアップのいずれの後でも安全にクリーンアップできるようにします。
• テストを再実行可能かつ冪等に保ちます。実行順序に依存したり、前回の実行状態を暗黙に再利用したりしてはなりません。
• 新しいエビデンスの設定、実行、解釈、クリーンアップの方法が、貢献者にとって他に分からない場合に限り、必要最小限のテストドキュメントを追加します。
• 本番コードの編集、アサーションの弱体化、根拠のないタイムアウトの延長、失敗ケースのスキップ、合格させるための期待値成果物の再生成を行わないでください。
• 差分を確認し、無関係な書式変更、生成物の不要な差分、シークレット、環境固有のパス、承認済みスコープ外の変更がないことを確認します。

4. 実行して証拠を保持する

• まず影響を受ける最小のシナリオを実行し、次に関連するテストスイートと、利用可能な場合は必須のリポジトリゲートを実行します。証拠を取り除く操作のみを行う場合は、置き換えとなる証拠、または最も近い保持対象の証拠を実行します。
• コマンド、作業ディレクトリ、環境クラス、対象、バージョン、終了ステータス、所要時間、成果物、実際に実行したシナリオを記録します。テストが選択されていない場合や、すべてスキップされた場合の出力では、受け入れを証明できません。
• 不具合を再現するために必要な、最初の失敗時の出力、シード、順序、リクエスト、レスポンス、スクリーンショット、差分、または永続状態を保持します。
• テストを変更する前に、製品の失敗、テストの不具合、環境の失敗、依存関係の利用不可、不安定な証拠を区別します。
• 有効なテストで製品の不具合が明らかになった場合は、失敗した受け入れ証拠を保持し、最小限の再現手順を報告します。製品コードは決して修正しません。安全な場合は、対象範囲内の独立したテスト作業を続けます。
• 状態の所有権または冪等性が重要な場合は、クリーンアップを検証し、少なくとも影響を受けるシナリオを再実行します。
• 非決定性の診断を目的としない限り、再試行は避けます。再試行によって最初の失敗が見えない成功に変わってはなりません。

5. 過大な主張をせずに最終化する

• 各要件と保護対象の結果を、最終的なテストパスまたは NONE、コマンドまたは代替の統制、オラクルまたは許容されたリスク、および PASS、FAIL、BLOCKED、UNPROVEN のいずれかの結果に対応付けます。
• 正当な逸脱を含め、計画したポートフォリオ操作と実際の操作を照合します。テストの追加、更新、統合、削除の正味件数を報告しますが、件数を品質目標として扱ってはなりません。
• 承認されたすべてのポートフォリオ操作が実装され、必要な証拠に信頼できる PASS、製品の FAIL、または正当な NO_TEST の統制が記録されている場合は、COMPLETE を使用します。未解決のテスト不具合は、完了した証拠とはみなしません。この判定は、製品の正しさを証明するものではありません。
• 安全な作業が未完了の場合、または環境、依存関係、テストの不具合、中断により信頼できる実行が妨げられる場合は、INCOMPLETE を使用します。残っている作業または確認事項を正確に記載します。
• 操作を安全に実装できない場合、要件に信頼できるオラクルがない場合、またはワークスペースを保護できない場合は、BLOCKED を使用します。

セルフチェック

• 返答前に照合します。 項目単位の証拠、要件の網羅性、矛盾、範囲、判定、および該当するクリーンアップを確認します。レポートまたは許可された成果物を修正します。有効な証拠は再利用し、リポジトリの再スキャンや成功済みコマンドの再実行を自動的に行ってはなりません。関連する変更、失敗、または未解決の証拠がある場合にのみ、確認を繰り返します。残る不足を開示します。

出力要件

次の順序ですべての項目を保持し、各事実を一度だけ記載して、ユーザーの言語で報告します。簡潔な結果の場合は各項目を1行にまとめてもかまいません。空の表は省略し、リンク先の成果物を複製して記載しないでください。

1. 結果： スキル固有の判定と、裏付けのある結果。
2. 範囲： レビューまたは変更した範囲、除外事項、ベースライン、および重要な前提。
3. 証拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別します。成果物にはリンクし、必要に応じて表を使用します。
4. 検証： 確認事項と結果、利用できなかった証拠、該当するクリーンアップまたは外部状態。
5. 完了状況： Checklist: X/Y complete。Incomplete: None、または各 UNPROVEN 項目の理由、結果への影響、正確な次のアクションを記載します。残存リスクと必要な判断も記載します。

スキル固有の証拠： 要件／保護対象の結果 → 既存の証拠 → ポートフォリオ操作 → 最終テストパスまたは NONE → 独立したオラクル／コマンド → ゲート／結果 → 廃止条件。変更したテスト／ドキュメントのファイル、統合または削除に伴う代替証拠、ポートフォリオへの正味の影響、正確なコマンドと成果物、保持した製品不具合の再現手順、クリーンアップ、利用できなかった環境、除外したセルを記載します。証拠が揃っていても、製品の正しさを意味するものではありません。