起動テスト・E2Eテストの整備

[hakatashi]

背景

ユニットテストのみに依存していたところ、起動時に問題が発生する不具合を見逃してしまった事例があった。ユニットテストだけでは検知できない不具合（起動時のクラッシュなど）がある。

提案

• 各botモジュールが正常に起動できることを確認する起動テストを追加する
• 最低限1つでもE2Eテスト（実際にbotを起動し、簡単なやりとりが通ることを確認するテスト）を用意する

補足

Slack #sandbox での議論より起票。

[tsg-ut-gemini-assistant]

えへ～

ありがとう！

レビューさせてもらうにゃ！

🔍️🔍️🔍️️

[tsg-ut-gemini-assistant]

🤖 I'm sorry @hakatashi, but I was unable to process your request. Please see the logs for more details.

[hakatashi]

技術調査メモ

このIssueの背景となった具体的な事故を特定しました。

根本原因

PR #1213 で fastify v4→v5 にアップグレードした直後、PR #1215 で FST_ERR_PLUGIN_INVALID_ASYNC_HANDLER により本番の全HTTPエンドポイントが未登録になる事故が発生していました。

fastify v5 では「async プラグインが callback 形式の第3引数 next を持つこと」が禁止されましたが、tunnel, tsglive, nojoin, google-calendar, amongyou, oogiri, slow-quiz の7プラグインが async (fastify, opts, next) => { ... next() } という禁止パターンを使っていたため、fastify.register() 実行時に例外が投げられ、deploy botを含む全HTTPエンドポイントの登録が失敗していました。

なぜ既存のテストで検知できなかったか

• ユニットテストは lib/slackMock.ts の SlackMock を使うが、これは実際の Fastify インスタンスに対して register() を行わないため、この検証ロジックを一切通過しない
• tsgo --noEmit（型チェック）も、Fastifyの実行時プラグイン登録検証（callback/async混在チェック）は静的型では検知できない領域

つまり「実際に Fastify に登録して初めて顕在化するクラス」のバグに対して、現在のテストピラミッドに構造的な穴があります。

提案する解決策

A. 起動スモークテスト（低コスト・高ROI）

• index.ts の productionBots/developmentBots 配列を lib/bots.ts 等に切り出す（index.ts はトップレベルIIFEでFastify起動・Slack投稿の副作用を持つため、そのままimportできない）
• 全プラグインを動的importし、
  1. plugin.default(mockSlackInterface) を呼んで初期化時クラッシュを検知
  2. server exportを持つプラグインは実際に fastify.register() → fastify.ready() まで実行し、Fastifyの実行時検証（今回のような async/callback混在エラー等）を通す
• SlackMock を再利用でき、実ネットワーク・実Slackトークン不要。既存の test-js CIジョブにそのまま追加可能

B. E2Eテスト（helloworld botのみに限定）

• helloworld は AGENTS.md 上も「最新の推奨パターン」の参照実装と位置付けられているため、E2E対象として最適
• 実プロセス（node .build/index.js --only helloworld）を起動し、ログに Server launched が出るまで待って /slack-event にダミー署名付きリクエストをPOSTし、レスポンス・副作用を確認後にプロセスをkill
• 全77 bot（本稿執筆時点）を対象にすると外部API依存や実トークンが必要なものも多く、遅く壊れやすいため、対象は1botに絞るのが現実的

進め方

まず A から着手し、別PRとして提出します。B は将来的な着手を見据えてこのコメントに技術詳細を残しています。