mcpField
T
test-against-spec

test-against-spec

github.com/frostneyテスト・品質043 回インストール3 日前に更新
リポジトリ

test-against-spec について

test-against-specは、提供された動作を明示的な仕様と照合するスキルです。既定では結果を報告し、正確な修飾子 `fix` がある場合は対象範囲の不備を修正して再テストします。ソースレビューや単体テストではなく、観察可能な動作を根拠にします。

主な機能

  1. 01明示的な仕様から期待動作を導出
  2. 02実際のインターフェースでテスト
  3. 03環境、操作、証拠を記録
  4. 04合格、失敗、未検証を分類
  5. 05`fix` モードで修正と再テスト

活用シーン

  1. 01機能と受け入れ条件の照合
  2. 02修正後の不具合再現と再テスト
  3. 03動作確認結果と未検証項目の報告

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/frostney/known-good-route --skill test-against-spec

インストール後、Claude Code で/test-against-specを入力して読み込まれたか確認します。

同梱ファイルreferences/fix-mode.md

詳細

仕様に照らしたテスト

提供された動作が明示的な仕様に一致しているかを確認します。 既定では結果を報告します。正確な修飾子 fix が指定された場合は、対象範囲内で確認された差異を修正し、再テストします。このスキルは、ソースレビューやリポジトリ全体のプロジェクトゲートの代わりになるものではなく、それらを実行するものでもありません。ソースレビューと単体テストの成功だけでは、動作の証拠にはなりません。

実装、要件、環境、入力が一致する場合は、記録済みの実インターフェイスの証拠を再利用します。ただし、fix モードでは、修正前に各失敗を実際に再現します。変更後、失敗後、または懸念事項が未解決の場合は、未実施または無効になった動作チェックを実行します。

範囲

  • 期待される動作は、ユーザーの依頼、課題、確認済みのミニ仕様、製品ドキュメント、ADR、またはその他の明示的な決定のみを根拠に導きます。実装から推測してはいけません。 重大な 対立や曖昧さがある場合は、作業を中止します。
  • 外部から観測可能な結果をテストします。ユーザー向けの動作には実際に表示される製品を使用し、それ以外の動作には実際の API、CLI、ライブラリエントリーポイント、ジョブ、パッケージ、マイグレーション、またはデプロイ済みサービスを使用します。 定性的な要件については、実際の成果物と動作をユーザーのリファレンスまたは受け入れ基準と比較します。メトリクスに合格しただけでは、視覚的な忠実度や使いやすさを立証できません。
  • 動作の証拠として、実装ソース、テストソース、単体テスト、モック、スナップショット、またはパッチを使用してはいけません。実行可能な動作を伴わない要件はこのスキルの対象外であり、コードレビューまたはプロジェクトゲートで扱います。
  • テスト対象の正確なリビジョンに紐づいたプレビュー環境が利用可能な場合は、そちらを優先します。適切なプレビューがない場合、または現在の作業変更を網羅するためにローカル実行が必要な場合は、ローカル環境を使用します。実際に提供されるインターフェイスをテストし、結果が最新である既存のブラックボックス自動テストを使用します。
  • ユーザーから別途許可されていない限り、この手順ではコミット、プッシュ、デプロイ、公開、外部データの変更を行いません。可能な場合は破棄可能なテストデータを使用し、テストによって重大な外部への影響が生じる場合は、事前にユーザーに確認します。

ワークフロー

  1. 仕様の参照元と、テスト対象の正確なワークツリーのリビジョン、コミット、またはプレビューリビジョンを記録します。外部から確認可能な要件と、このスキルの対象範囲外の要件を分け、上記の境界に従って各動作に適した環境を選択します。
  2. テスト可能な要件をすべて検証します。想定される経路と、最も重大な失敗経路または境界経路を確認します。ユーザー向けの変更では、レンダリングされた製品を操作し、影響を受ける状態、アクセシビリティ、および関連するビューポートを確認します。
  3. 環境、セットアップ、操作またはコマンド、入力、期待される結果、観測された結果を記録します。テスト対象の正確な内容に対して期待した結果が観測された場合にのみ、要件は合格です。結果のないチェックの提出や確認応答は合格ではありません。再実行してください。
  4. 現在のプレビューでもローカル環境でも必要な動作を再現できない場合は、プロジェクトのドキュメントとスクリプトを調べ、サンドボックス、エミュレーター、ハーネスなどの別の方法を探して使用します。利用できる方法がない場合に限り、その動作を未検証とし、試した方法を報告します。
  5. fix がない場合、編集は行いません。fix がある場合は、実装ソースを調べる前に、fix が指定されたらすぐにreferences/fix-mode.mdを読み、失敗した要件すべてに対してその手順に従います。

コミット済みまたは無視対象の成果物ではなく、アクティブなワークフロー内で構造化された概要を返します。テスト対象のリビジョン、環境、仕様の参照元、各要件と、その証拠または制約をpassed、failed、unverified、out of scopeのいずれかで示します。該当する場合は、修正内容と変更したファイルも含め、失敗または未検証の動作が残っているかどうかを記載します。直接開始した場合は、delivery settingsに従って続行します。entry-points: deliverの場合は、修正を含むテスト済みの変更を/deliverに引き継ぎます。/deliverは、設定されたエンドポイントに公開するまでレビューとゲート処理を行います(ORCHESTRATION.mdがない場合はready-to-merge)。stopの場合は、この概要をもって終了します。

コメント