mcpField
T
test-slack-app

test-slack-app

github.com/slackapiテスト・品質161439 回インストール2 日前に更新
リポジトリ

test-slack-app について

既存の Slack アプリが動作するかを開発者が手動で確認するためのスキルです。登録済みのリスナーを調べ、具体的な操作と期待される結果を示します。自動テストスイートを実行するものではありません。

主な機能

  1. 01安全なワークスペースでアプリを確認
  2. 02CLI の診断とマニフェスト検証
  3. 03登録済みのアプリ操作を調査
  4. 04操作と期待結果の手順を提示
  5. 05ログで応答を確認

活用シーン

  1. 01スラッシュコマンドの応答を確認
  2. 02イベントやショートカットの処理を確認
  3. 03モーダル送信が動作するか確認
  4. 04手動確認中のエラーを調査

インストール

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

$npx skills add https://github.com/slackapi/slack-skills-plugin --skill test-slack-app

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

詳細

Slack アプリのテスト

開発者がすでに作成した Slack アプリが実際に動作することを確認します。これはビルドループの最後のステップです。slack:create-slack-app スキルでアプリのひな形を作成し、slack:slack-cli スキルで実行した後に行います。

方法はシンプルで安全です。

  1. **開発者用サンドボックスまたは Free Team でアプリを実行します。**できればサンドボックスを使用するか、この目的で開発者が作成した Free Team を使用します。実際の同僚がいるワークスペースは絶対に使用しないでください。
  2. アプリのソースを確認し、実際に何を受け取るよう設定されているかを把握します。
  3. Slack で実行する具体的な手順を開発者に伝え、アプリが応答することを一緒に確認します。

これは、自動テストスイートではなく、ガイド付きの手動確認です。セットアップを進め、開発者に入力またはクリックする内容を伝え、表示された内容を確認してもらいます。Slack CLI で管理されるアプリに最適ですが、ステップ 2 では通常の Bolt アプリ向けのベストエフォートの手順も用意しています。


ステップ 1:安全なテスト環境を用意する

1a. Slack CLI を検出する

slack:slack-cli スキルのステップ 1:Slack CLI を検出するを使用して、公開版 Slack CLI がインストールされているか確認し、コマンド名を特定します。フィンガープリントの確認、エイリアスへのフォールバック、インストール手順はすべてこのスキルに記載されています。ここで重複して説明しないでください。以降は、特定したコマンドを SLACK_CMD として参照します。CLI がインストールされていない場合は、アプリの実行に必要なため、同じ手順でインストールするよう開発者を案内してください。

1b. テストに使う安全なワークスペースがあることを確認する

テストには、誰も作業していないワークスペースを使います。できれば開発者用サンドボックスを使用するか、この目的で開発者が作成した Free Team を使用してください。実際の同僚がいるワークスペースは絶対に使用しないでください。

  • ここにある情報ではなく、最新のドキュメントをもとに説明してください。slack:slack-docs スキルを使用して、https://docs.slack.dev/tools/developer-sandboxes.md を取得し、その内容を要約してください。これにより、古くなった情報を参照するのではなく、常に最新のドキュメントに基づいて推奨できます。Slack がアプリの開発とテストにサンドボックスを推奨していることを開発者に伝えてください。
  • 現在の対象を確認します。SLACK_CMD auth list を実行して、認証済みのワークスペースとチーム ID を確認します。また、プロジェクトディレクトリから SLACK_CMD app list を実行して、すでにインストールされているアプリとその ID を確認します。
  • **対象が安全であることを確認します。**CLI では、サンドボックス、Free Team、実ユーザーが多数いるワークスペースを区別できないため、現在どれに接続しているかを開発者に尋ねてください。サンドボックス、またはこの目的で開発者が作成した Free Team であれば問題ありません。同僚がいるワークスペースは使用できません。その場合は作業を中断し、ほかの 2 つのいずれかを使うよう案内してください。
  • 安全な対象がまだない場合は、slack:create-slack-app スキルのステップ 3:アプリのインストール先を選ぶを使ってセットアップします。対象の優先順位、sandbox list/sandbox create の手順、Developer Program へのリンクはこのスキルに記載されています。どちらの方法でも最後はブラウザーを使うため、ワークスペースが作成され、ログインできたらここに戻るよう開発者に伝えてください。
1c. 簡易ヘルスチェック

時間のかかる手動確認に進む前に、CLI 独自の検証機能を使って、明らかなセットアップの問題を確認します。

  • SLACK_CMD doctor:CLI、言語ランタイム、認証を確認します。
  • SLACK_CMD manifest validate:アプリにマニフェストがある場合は、プロジェクトディレクトリから実行して、アプリの設定が正しい形式であることを確認します。

次に進む前に、これらのコマンドで見つかった問題を提示してください。


ステップ 2:アプリを実行する

以下のどの方法を使う場合も、テスト時にできるだけ多くの情報を得られるよう、まずアプリのログレベルをデバッグに設定してください。開発者のコードを変更せずに済む方法を優先します。ロガーの設定を確認し、ログレベルの環境変数を読み取るかどうかを調べてください(テンプレートによっては、SLACK_LOG_LEVEL や LOG_LEVEL などが設定されています)。環境変数を読み取る場合は、ソースを編集せず、その変数を設定してください。CLI で管理されるアプリでは、SLACK_CMD env set <LOG_LEVEL_VAR> debug を実行すると、slack run が読み込むプロジェクトの .env に保存されます。通常の Bolt アプリでは、アプリがすでに読み込んでいる環境または .env で設定してください。ロガーがそのような変数を読み取らない場合に限り、ソースを編集し、ログレベルが設定されている箇所を見つけて、この実行時にデバッグへ切り替えてください。

CLI で管理されるアプリ(推奨)

slack:slack-cli スキルの ステップ 6:アプリをローカルで実行する(slack run) に従い、ローカル開発サーバーをバックグラウンドで起動してください。これにより、アプリが対象のワークスペースにインストールされます。まだ何もインストールされていない、新しいサンドボックスや Free Team では重要です。起動後は、ファイルの変更が自動で再読み込みされます。

CLI を使わない通常の Bolt アプリ(ベストエフォート)

Slack CLI ではなく node や python で起動する通常の Bolt アプリでも、このスキルを利用できますが、実行方法はベストエフォートであり、主要なフローではありません。

  • アプリをテスト用ワークスペースに接続します。そのワークスペースのアプリ設定にあるボットトークンとアプリレベルトークンを、アプリが読み込む環境または .env ファイルに設定してください。
  • アプリにパブリック URL が不要なソケットモードを優先してください。これは、アプリがソケットモード用に実装され、アプリレベルトークンに connections:write がある場合にのみ機能します。HTTP 用に作成されたアプリにトークンを追加しても、イベントは届きません。
  • アプリ独自のコマンド(たとえば npm start や python app.py)で起動し、ログを確認してください。

この方法はベストエフォートであり、最もスムーズに利用できるのは CLI で管理されるアプリであることを明確に伝えてください。


ステップ 3:Slack で試して動作を確認する

このスキルの中心となるステップです。開発者に一般的なチェックリストを渡してはいけません。すべてのステップを、実際にこのアプリが登録している内容に基づいて説明してください。

3a. ソースを読んで、アプリが待ち受けているものを確認する

アプリのリスナーコードを読み、登録されているインタラクションを列挙してください。フレームワークによって、次のようなものがあります。

  • スラッシュコマンド: /ship などの登録済みコマンド名。
  • ショートカット: コールバック ID を持つグローバルショートカットまたはメッセージショートカット。
  • イベント: app_mention、message、reaction_added などの購読イベント。
  • アクション: アクション ID を持つインタラクティブコンポーネント(ボタン、セレクトなど)。
  • ビューの送信: モーダルの送信ハンドラー(view_submission)。
  • App Home: app_home_opened ハンドラー、または公開済みの Home タブ。
  • アシスタント/エージェント: アシスタント、または assistant_thread_started ハンドラー。エージェントテンプレートでよく使われます。

プレースホルダーではなく、見つかった具体的な識別子(実際のコマンド名やコールバック名)を挙げてください。

3b. 各項目を「この操作をして、こうなることを確認する」手順にする

登録されている各インタラクションについて、具体的な操作と、正常に動作するアプリがその操作にどう応答するかを開発者に伝えます。わかりにくい箇所がいくつかあるため、明確に説明してください。

  • スラッシュコマンド → テスト用ワークスペースのチャンネルまたは DM でコマンド(たとえば /ship)を入力します → ハンドラーが送信する応答が返ってくることを確認します。
  • グローバルショートカット → ショートカットメニューを開き(クライアントによって、メッセージ作成欄にある稲妻アイコンまたは + ボタンを使用します)、ショートカットを選択します → 開いたモーダルまたはメッセージを確認します。
  • メッセージショートカット → メッセージにカーソルを合わせて その他のアクション(⋯ メニュー)を開き、ショートカットを選択します → 応答を確認します。
  • app_mention などのイベント → アプリが参加しているチャンネルでアプリに @-メンションします → 返信があることを確認します。
  • ボタンまたはセレクトメニュー → アプリが投稿したメッセージまたはモーダル内のコンポーネントをクリックします → アクションハンドラーの処理結果を確認します。
  • モーダル送信(view_submission) → モーダルを送信します → 確認メッセージまたは副作用を確認します。
  • App Home → 左サイドバーでアプリをクリックして Home タブを開きます → 公開されたビューを確認します。
3c. 動作を確認して報告する

開発者が操作している間、正常に動作していることを確認できるよう支援します。

  • アプリを slack run で実行している場合は、そのログを確認します(「slack run の出力を見せてください」と尋ねます)。イベントが届いていることを確認し、エラーを読み取ります。
  • 応答に問題がある場合(メッセージや Block Kit ビューの形式が正しくない、または API エラーが発生するなど)は、slack:block-kit と slack:slack-api のスキルを使ってペイロードやメソッドを調べます。

最後に、確認できた動作と、開発者自身が目視で確認すべき点を簡潔にまとめます。これは手動での確認です。自動的に合格・不合格を判定するのではなく、アプリの応答を開発者と一緒に確認します。


注意事項

  • SLACK_CMD はプレースホルダーです。必ず Step 1a で特定した実際のコマンド名に置き換えてください。
  • 対象範囲:このスキルは、すでに存在するアプリをテストします。アプリの作成またはひな型の生成には slack:create-slack-app スキルを、CLI の基本操作には slack:slack-cli スキルを、メッセージまたは Block Kit の書式設定には slack:slack-messaging と slack:block-kit のスキルを使用してください。
  • 現時点では対象外:Bolt 用の自動テストフレームワーク、ユーザー操作のプログラムによるシミュレーション、ブラウザーを使った Slack UI の操作。開発者自身が操作を行い、このスキルはその手順と期待される結果を明確にします。

コメント