OxideTerm テスト監査 は何をしますか?
振る舞いを所有するレイヤーで有用なリグレッション保護を維持します。要求された変更を解決する最小のレビューを使用し、結果はテスト数や削除行数ではなく、保護された契約と検出されたエラーによって判断します。
該当する AGENTS.md をお読みください。リポジトリルートからコマンドを実行します。検証マトリックス と テストガイド はプロジェクト固有のチェックを定義します。このスキルはテスト品質の意思決定を提供します。
スコープの選択
- テストの作成または変更: その振る舞いに対して作成上の質問を適用し、最も近い既存のカバレッジを検査します。
- 障害の診断: 編集前に、テストが失敗した理由を確立し、実装、期待値、フィクスチャ、または環境のいずれが間違っているかを判断します。
- 既存のテストの監査: 要求されたモジュールまたは振る舞いをレビューし、提案された各変更の証拠を記録します。要求された場合にのみ、サブシステム全体に拡張します。各バッチに同じ証拠基準を使用します。
このスキルの作成または呼び出しは、広範なクリーンアップ、サブエージェント、コミット、プッシュ、またはPRを許可するものではありません。ユーザーの既存の許可およびレビューのみの境界を尊重します。編集がすでに許可され、証拠が十分である場合は、追加の承認ラウンドなしで進めます。
作成上の質問
テストを追加または変更する前に、以下を特定します。
- 保護される観測可能な振る舞いまたは独立した契約。
- もっともらしいリグレッションと、それが失敗する特定のアサーション。
- 最も近い既存のカバレッジが見逃しているもの。該当する場合はそのカバレッジを拡張します。別のレイヤーには、異なる統合、プロトコル、またはライフサイクルリスクが必要です。
- テストが、ビジネス上の呼び出し元のない本番エクスポート、スイッチ、ラッパー、またはインジェクションフックを必要とするかどうか。既存の所有境界でテストすることを優先します。
実装とは独立した期待値を使用します。フィクスチャは、正しい振る舞いと考えられるバグを区別する必要があります。フィルタをテストする場合は除外候補を含め、ソートをテストする場合は異なる順序キーを含め、編集をチェックする場合は実際の機密入力を含めます。コンストラクタフィールドのラウンドトリップ、空でない結果、またはアサートされている振る舞いを実行するモックは、意図されたワークフローの十分な証拠ではありません。
テストヘルパーとフィクスチャは、テスト専用であっても正当な場合があります。懸念事項は、本番APIを歪めたり、テストのためだけに廃止された本番動作を維持したりすることです。
失敗したテストの診断
完全なテスト、その入力、本番パス、近隣のカバレッジ、および関連する変更履歴を読みます。CIの場合、失敗したコミット、ジョブ、テスト名、アサーションを特定します。一般的な非ゼロ終了コードは根本原因ではありません。クレームがその動作に依存している場合は、依存関係のソースまたはタイプを検査します。
証拠から障害を分類します。
- 製品リグレッション: 意図された契約は依然として有効です。障害を再現し、許可された範囲内で所有する実装を修復します。
- 時代遅れの期待: 履歴と現在の契約は、意図的な動作変更を示しています。サポートされているリリース形式とAPIの保護を維持しながら、期待される動作を更新します。
- 欠陥のあるテストまたはフィクスチャ: ケースが主張する条件を実行していない、偶発的な状態に依存している、または無関係な理由で失敗しています。実際の境界でセットアップとアサーションを修復します。
- 環境障害: コンパイル、依存関係、リソース、プラットフォーム、または外部フィクスチャによって動作のテストが妨げられています。その制限を報告します。合格テストや時代遅れのテストとして再解釈しないでください。
ベースラインの失敗はテストを削除する理由にはなりません。バグ修正の場合、修復前の意図された障害と修復後の成功を示します。同じ障害を証明する場合は、有効なCI証拠またはキャプチャされたローカルベースラインを再利用します。儀式のために高価なチェックを繰り返さないでください。
たとえば、.oxide プラグインテストは、パスワードなしの検証と復号化されたインポートプレビューを区別する必要があります。暗号化形式の検証応答はメタデータを明らかにしてはなりません。パスワードを含むプレビューには、明示的に期待される説明と接続名が含まれている必要があります。これらのアサーションを更新することで、プラグインレイヤーでの別の低レベルの復号化テストなしに契約を保護します。
編集前の監査
各候補をパラメータ行も含めて完全に読みます。その本番エントリポイント、呼び出し元、関連する依存関係、兄弟実装、重複するテストをトレースします。そのテストが存在する理由の履歴と、実際に実行されるチェックのCIルーティングを確認します。
提案された変更については、作業中の応答にコンパクトな証拠記録を使用します(保存されたレポートが要求されていない限り)。
| テストと場所 | 動作ともっともらしい障害 | 決定 | 残存または修復された証拠 | 検証 |
|---|---|---|---|---|
| 正確なテスト名とパス | アサーションが検出できるもの | 保持 / 修正 / 統合 / 削除 | 名前付きテストまたは境界(関連する履歴を含む) | 対象を絞ったコマンドまたは手動シナリオ |
- 保持: 意味のある契約を独立して保護します。
- 修正: 動作は重要ですが、入力、アサーション、名前、または期待される結果が間違っているか、弱すぎます。
- 統合: 重複するセットアップまたはケースを削除する前に、異なるアサーションを指定されたプライマリテストに移動します。
- 削除: より強力な残存証拠を指定するか、その動作にサポートされている契約がなくなったことを示します。不確実性がある場合は調査するか保持します。
テストと共に本番コードが削除された場合は、そのコードの非テスト呼び出し元と、コードが廃止された理由も特定します。ヘルパー、エクスポート、機能、またはフィクスチャを削除する前に、参照を検索します。監査の一部として無関係な簡略化を行わないでください。
調査する価値のあるパターン
- テストが実装のソーステキスト、プライベート呼び出しの形状、または正確な内部表現を繰り返しており、動作を保持するリファクタリング後に失敗します。
- 複数のレイヤーが同じヘルパーを同等の入力で呼び出し、独自の統合を実行せずにそのアサーションを繰り返しています。
- フィクスチャが、実際の所有者が生成すべきコールバック順序、完了通知、または永続化された結果を事前に準備しています。
- 拒否テストが、テストしようとしている権限チェックに到達する前に、パラメータ検証によって拒否されています。
- 並行性、キャンセル、またはウェイクアップテストが、競合する作業や待機者を作成せずに、最終的なフラグのみをチェックしています。
- 成功アサーションが、コンテンツ、同一性、順序、または永続的な副作用が契約である場合に、
Ok、Some、長さ、または空でないことのみをチェックしています。
これらは調査のシグナルであり、自動削除ルールではありません。独立したセキュリティデフォルト、プロトコルバイト、永続性と移行形式、プラグインAPI、プラットフォーム動作、パッケージング、国際化、アーキテクチャ制約を保持します。静的検査は、実際の契約を保護し、無関係な名前変更に耐えられる場合に有用です。実行が遅いことだけではテストが冗長になるわけではありません。
OxideTerm の境界
| 動作 | 推奨される検証境界 |
|---|---|
| 解析、設定の正規化、シリアル化、またはデータマージ | 明示的な期待値とサポートされている形式のサンプルを使用した、所有するドメインクレート |
| SSHノード共有、SFTP、転送、再接続、またはジャンプホスト | 実際のコンシューマ登録、キャンセル、クリーンアップを伴うランタイム所有者。ランタイム所有権 を参照。 |
| 混合ページ、フォーカス、ポップアップ、または遅延UI結果 | 既存のGPUIテストコンテキストと機能エンティティ。ネイティブIME、ウィンドウ、GPUの動作は、依然としてホスト検証が必要です。 |
| プラグイン、MCP、またはCLIアダプター | 実際のディスパッチと返されるデータ、権限、ターゲットID、または副作用。ドメインヘルパーだけを再生することは避けてください。 |
| 編集と資格情報のライフサイクル | 関連する出力または所有権境界を介した合成シークレット入力。機密データ を参照。 |
| パッケージングとリポジトリスクリプト | 既存のスクリプトテスト、または検証マトリックスによって選択された実際のドライラン契約 |
共有ノードテストの場合、1つの端末を閉じても、別の実際のコンシューマは使用可能である必要があります。古くなった結果の処理の場合、所有者が変更された後に古い完了を配信します。既存のフィクスチャとイベント駆動型の同期を使用します。任意のスリープと追加のリトライでは、これらの条件を確立できません。
検証と終了
テスト実行を開始する前に、関連するソース/テストの編集を完了します。その実行中はチェックアウトを安定した状態に保ちます。
- 対象のテストまたはモジュールを実行します(例:
cargo test -p <crate> <test_filter>)。実際にそれを所有するターゲットとプラットフォームを使用します。デスクトップテストはoxideterm-gpui-appのoxideterm-nativeバイナリターゲットにあります。スタンドアロンのリモートエージェントは--manifest-path agent/Cargo.tomlを使用します。 - 結果を読み、意図したテストが実際に実行されたことを確認します。一致するテストがゼロの成功したコマンドは証拠になりません。削除または移動後は、名前付きの残存カバレッジと、影響を受ける個別の統合チェックを実行します。
- Rustの編集については、
cargo fmt --checkとgit diff --checkを実行します。検証マトリックスに従って、クレートチェック、スクリプトテスト、ロケール監査、または手動ワークフローを追加します。関連する変更や新しい証拠によって無効になるまで、結果を再利用します。 - 最終的な差分とステータスを確認します。固有の動作が消えていないこと、製品の失敗を隠すためにアサーションが弱められていないこと、無関係な作業が変更されていないことを確認します。
アサーションに関する具体的な疑問を解決するために必要な場合にのみ、意図的なミューテーションを使用します。ユーザーの作業から隔離し、後に正確なソースを復元し、すべてのテストにそれを要求しないでください。サブシステム全体の監査では、最終的な影響を受けるスイートを実行する前に、削除されたケースを名前付きの残存テストと照合する必要があります。
決定、依然として保護されている動作、実際に実行されたチェック、および重要な未検証の境界を報告します。削除が発生した場合は、削除されたカバレッジを説明します。要求されたスコープが完了したら停止します。カウントまたは削減目標を達成するために監査を拡大しないでください。
出典
OpenClaw の test-audit および campaign ガイダンス におけるテスト価値と証拠の原則から改変されました。実行、所有権、および検証は、ここでは OxideTerm のリポジトリルールに従います。