Skip to content
Cocot Wiki

E2Eスモークテスト（curlベース）

何のためのものか

ユニットテスト（internal/works・internal/uploadsの_test.go）はDBやFirebase・S3を実際に叩かずfakeで検証するのに対し、こちらは実際に起動しているスタック（docker compose up + 実Postgres + 実Garage + 実Firebase）に対して本物のHTTPリクエストを送り、エンドツーエンドで動作確認するもの。人間が手動でcurl/Postmanを叩く作業をスクリプト化し、再現可能にしたもの。

TDDのユニットテストでは発見できない種類のバグ（インフラ・外部ライブラリの実際の挙動起因のバグ）を実際にこの方法で発見した実績がある。詳細はtesting/known-findings参照。

構成

scripts/
  lib/
    firebase.sh      # Firebase Auth REST APIのサインイン/サインアップ共通関数（source専用）
  get-token.sh        # 単発でIDトークンを取得するCLI（curl/Postman向けの手動テスト補助）
  e2e-smoke.sh         # 本体のE2Eスモークテスト一式

scripts/lib/firebase.shはsourceして使う共通ライブラリで、firebase_sign_in（既存ユーザーのサインイン）とfirebase_sign_up（新規ユーザー作成）を提供する。get-token.shとe2e-smoke.shはどちらもこれを使う。jqへの依存を避け、grep/sedによる軽量なJSON抽出をしている（開発環境によってはjqがPATH解決できないことが判明したため）。

前提条件

  • バックエンドが起動していること（docker compose up、またはpostgres/garageのみDockerで起動しgo run ./cmd/appをホストで実行）。
  • Firebaseのメール/パスワード認証が有効な、同じFirebaseプロジェクト内のテストアカウントが2つ（所有者用・非所有者用）。
  • curl・base64（標準的なGit Bash/POSIX環境に含まれる）。
  • 実変換の検証（後述）には、ローカルのffmpeg（テスト用音声ファイルの生成に使用、アプリ本体の動作には無関係）と、docker composeを実行できるdockerコマンド（uploadsテーブルの状態確認に使用）が追加で必要。どちらか欠けている場合はこの部分の検証だけSKIPされる。

使い方

単発でトークンだけ取得（手動でcurl/Postmanを叩く用途）:

Terminal window
FIREBASE_API_KEY=... ./scripts/get-token.sh test@example.com exampletest0000

新規テストユーザーを作る場合:

Terminal window
FIREBASE_API_KEY=... ./scripts/get-token.sh test-b@example.com exampletest0000 --signup

E2Eスモークテスト一式を実行:

Terminal window
FIREBASE_API_KEY=... \
USER_A_EMAIL=... USER_A_PASSWORD=... \
USER_B_EMAIL=... USER_B_PASSWORD=... \
./scripts/e2e-smoke.sh

BASE_URL（デフォルトhttp://localhost:8000）で対象を変更可能。失敗があれば非ゼロ終了コードを返す。

検証内容

  • ハッピーパス: POST /api/works（下書き作成）→PATCH /api/works/:id（タイトル/説明/タグ設定）→POST /files（TUSアップロード開始）→PATCH /files/:id（チャンク送信）→HEAD /files/:id。
  • 所有者チェック: 別ユーザーによるHEAD/PATCH/DELETE /files/:idが403になること、存在しないuploadへのアクセスが404になること、他人のwork_idに対するPOST /filesが404になること。
  • エッジケース: 未認証リクエストの401、work_id欠落/不正な400、二重アップロードの409。
  • 実変換: ffmpegで生成した2秒のサイン波音声を実際にアップロードし、Workerが変換を完了するまで（最大30秒）ポーリングで待ち、uploads.status=done・duration_seconds・converted_sizeが正しく記録されることをDB直接照会で確認する。これはGET /api/works等のAPI経由では確認できない内部状態のため、docker compose exec postgres psqlで直接見ている。

FIREBASE_API_KEYについて

backend/cmd/app/dashboard/upload.html（手動アップロードテスト用ダッシュボード）で既に使われているものと同じ、Firebase Web APIキー。Firebaseの設計上これは公開情報であり（アクセス制御はFirebase Auth自体が行う）、秘匿情報として扱う必要はない。