mcpField
M
meticulous-test

meticulous-test

github.com/alwaysmeticulousテスト・品質108.6k 回インストール今日更新
リポジトリ

meticulous-test について

Meticulousでフロントエンドのビジュアルテストを行うためのスキルです。開発者向けに、ビルドのアップロード、テスト実行、結果確認をCLIまたはMCPで進める手順を示し、未コミット変更の扱いも説明します。

主な機能

  1. 01フロントエンド成果物のビルドとアップロード
  2. 02指定した基準コミットに対するテスト実行
  3. 03複数の基準でデプロイを再利用
  4. 04スクリーンショット、DOM差分、タイムラインの確認

活用シーン

  1. 01フロントエンド更新の視覚的な変更確認
  2. 02一つのビルドを複数の基準コミットと比較

MCP 対応

MCP経由でビルドのアップロードURLを取得して登録し、テストを実行する手順を示します。MCPでの実行には基準情報の明示が必要で、完了を待たずに返ります。

インストール

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

$npx skills add https://github.com/alwaysmeticulous/skills --skill meticulous-test

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

詳細

Meticulous を使用してフロントエンドの変更をテストするには、以下のワークフローに沿って、CLI または MCP コマンドを使いながら手順を進めてください。

開始する前に、meticulous-cli-update スキルを実行して、Meticulous CLI とスキルが最新であることを確認してください。ただし、この会話の前のほうですでに実行している場合は、スキップしてください。

テスト実行 ID がすでに指定されている場合は、ステップ 4 に進んでください。

ステップ 1 -- フロントエンドをビルドする

  1. CI 設定で該当するステップを確認し、Meticulous が必要とするビルド成果物を調べます。
    • GitHub：.github/workflows/*.yml で uses: alwaysmeticulous/report-diffs-action/upload-assets@v1（ビルドアセット）または upload-container@v1（Docker イメージ）を確認します。
    • GitLab：.gitlab-ci.yml（またはインクルードされている .gitlab/ci/*.yml）で npx @alwaysmeticulous/cli ci upload-assets（ビルドアセット）または ci upload-container（Docker イメージ）を確認します。
    • Bitbucket：bitbucket-pipelines.yml で同じ npx @alwaysmeticulous/cli ci upload-assets／ci upload-container ステップを確認します。
  2. CI 設定で使用されている手順に従って、フロントエンドをビルドします。

ステップ 2 -- ビルドをアップロードする

agent upload-build を使って、ビルドを再利用可能なデプロイとして登録します。このコマンドは成果物をアップロードし、deploymentId を標準出力に表示します。まだテスト実行は開始しません。

# CLI
meticulous agent upload-build --appDirectory <path-to-build>     # assets
meticulous agent upload-build --localImageTag <image-tag>        # container

# MCP (not 1:1 — request an upload URL, upload the artifact yourself, then register it)
request_asset_upload(size=<zipByteSize>)      # or request_container_upload() — no required args
# ... upload the zip/image to the returned URL/registry yourself ...
register_asset_build(uploadId="<id>", commitSha="<sha>")      # or register_container_build(uploadId="<id>", commitSha="<sha>")
  • --appDirectory にはビルド出力ディレクトリ（例：dist/ サブフォルダー）を指定します。--localImageTag にはローカルの Docker イメージタグを指定します。ビルドモードは自動検出されます。
  • ビルドのコミットはデフォルトでローカルの git HEAD になります。作業ツリーに変更がある場合、その内容は一時コミットとして記録されます（commitSha (local, ephemeral due to dirty working tree): … と表示されます）。下記の未コミット変更に関する注意を参照してください。
  • 追跡されていないファイルは記録できないため、受け付けられません。先に git add してください。
  • 標準出力から deploymentId を取得してください（--verbose を指定すると、標準エラー出力にも進行状況が表示されます）。

ステップ 3 -- テスト実行を開始する

デプロイに対するテスト実行を、ベースと比較して開始します。リポジトリのディレクトリから実行すると、ベース（origin のデフォルトブランチとのマージベース）と git diff が自動的に推定されます。

# CLI
meticulous agent trigger-test-run --deploymentId <deploymentId>

# MCP (never infers `baseSha`/`gitDiffOutput` — pass them explicitly — and always returns immediately without waiting for the run to finish)
trigger_test_run(deploymentId="<deploymentId>", baseSha="<sha>")
  • ベースの指定は必須です。現在のディレクトリから自動的に推定されます。または --baseSha <sha>（および必要に応じて --gitDiffOutput）を指定して明示できます。
  • --deploymentId を省略すると、代わりにローカルの HEAD コミット用にすでにアップロードされた最新のデプロイが使われます。この場合、作業ツリーがクリーンである必要があります（未コミットの変更がないこと）。
  • デフォルトでは、実行が完了するまでコマンドはブロックされ、testRunId を標準出力に表示します。視覚的な差分が検出されると、最終ステータスは Failure になります（これは通常の完了判定であり、エラーではありません）。実行の開始後すぐに戻るには、--dontWaitForTestRunToComplete を指定してください。
  • 1 つのビルドを複数のベースに使用： 同じ deploymentId を異なるベースに対して再実行できます。異なる --baseSha を指定して agent trigger-test-run を再実行してください。再ビルドや再アップロードは不要です。

出力から testRunId を控えてください。

ステップ 4 -- 視覚的な変更を確認する

meticulous-review スキルに、ステップ 3 の testRunId を渡して実行してください。このスキルは差分の概要を取得し、代表的なスクリーンショット／DOM 差分／タイムラインを調査して、各視覚的変更を意図したものか意図しないものか分類した最終レポートを作成します。

未コミットの変更： 作業ツリーに変更がある状態でビルド／テストした場合、実行は HEAD ではない（プッシュもされていない）一時コミットに対して記録されます。ローカルのチェックアウトから実行を特定するコマンド（--testRunId を指定せずに実行する meticulous-review／agent test-run-diffs）ではコミットから実行を見つけられないため、その場合はレビューの手順で必ず明示的に --testRunId を指定してください。

コメント

Markdown 対応