統合テストスクリプトをtmp/配下の作業ディレクトリで実行するよう改善
統合テストスクリプトがリポジトリのルートディレクトリを汚染する問題を修正しました。スクリプトがtmp/配下の独立したディレクトリで動作するようになり、テスト実行がクリーンかつ冪等になります。
背景
従来の統合テストスクリプトは、実行環境としてリポジトリのルートディレクトリをそのまま使用していました。これにより、テストを実行するたびにリポジトリ本体のGemfileとGemfile.lockが書き換えられ、作業ディレクトリにMy Workspaceが生成されるという問題がありました。
具体的には、テスト開始時にbundle remove actionmailerやbundle remove railsを実行してGemfileをクリーンアップし、rm -f Gemfile.lockでロックファイルを削除するという方法で状態のリセットを試みていました。しかしこのアプローチは、テスト実行中に割り込みが発生した場合や並列実行時にリポジトリの状態を壊すリスクを持っていました。また、bundle add tailwindcss-rails --path="../.." という相対パス指定は、実行時のカレントディレクトリに依存するため、スクリプトをどこから呼び出すかによって正しく機能しない恐れがありました。
これらの問題は、テスト実行環境の独立性という基本原則に反しており、CI環境や開発者のローカル環境での再現性を損なう要因となっていました。
技術的な変更
両スクリプトにROOT変数とWORKDIR変数を導入し、スクリプト自身の絶対パスを起点に作業ディレクトリを決定するよう変更されました。
スクリプト冒頭で以下のようにパスを解決し、専用の作業ディレクトリに移動します：
ROOT="$(cd "$(dirname "$0")/../.." && pwd)"
WORKDIR="$ROOT/tmp/integration-user-install"
rm -rf "$WORKDIR"
mkdir -p "$WORKDIR"
pushd "$WORKDIR"
Gemfileの準備方法も根本的に変わりました。従来はリポジトリのGemfileをbundle removeで整理していましたが、新方式ではヒアドキュメントで最小限のGemfileをゼロから生成します：
変更前:
rm -f Gemfile.lock
bundle remove actionmailer || true
bundle remove rails || true
rm -f Gemfile.lock
bundle add rails --skip-install ${RAILSOPTS:-}
変更後:
cat > Gemfile <<EOF
source "https://rubygems.org"
EOF
bundle add rails --skip-install ${RAILSOPTS:-}
また、テスト対象のgemへのパス指定が相対パスから絶対パスに変更されました。--path="../.." の代わりに --path="$ROOT" を使用することで、pushd によるディレクトリ変更後も正しくgemを参照できます：
# 変更前
bundle add tailwindcss-rails --skip-install --path="../..."
# 変更後
bundle add tailwindcss-rails --skip-install --path="$ROOT"
同様の変更がuser_install_test.shとuser_upgrade_test.shの両スクリプトに適用されており、作業ディレクトリはそれぞれtmp/integration-user-install/とtmp/integration-user-upgrade/に分離されています。
設計判断
スクリプトが自身の配置場所からルートを解決する方式を採用することで、スクリプトの実行可搬性を高めています。$(cd "$(dirname "$0")/../.." && pwd) というイディオムは、シンボリックリンクの解決には対応しないものの、bashスクリプトで広く使われる標準的な手法です。
作業ディレクトリをリポジトリのtmp/配下に置く選択は、.gitignoreの慣習に沿ったものです。tmp/はRailsプロジェクトで一般的に無視されるディレクトリであり、テスト生成物がリポジトリの追跡対象に混入するリスクを排除できます。また、テスト開始時にrm -rf "$WORKDIR"で作業ディレクトリを毎回クリーンアップする設計により、前回のテスト実行の残骸が次回に影響しない冪等性が保証されます。
既存の「スペースを含むディレクトリ名でのテスト」（My Workspace、#176、#184 で報告された問題）は引き続きWORKDIR配下に作成されており、その検証ロジック自体は変更されていません。
まとめ
本PRはテストコードの振る舞いを変えることなく、テスト実行の副作用をリポジトリのルートから隔離することに集中した改善です。Gemfileを「整理する」アプローチから「作り直す」アプローチへの転換と絶対パスの採用により、テスト環境の独立性と再現性が向上しました。