複数のテスト自動化ツールを検証していたら、PCが「環境変数の地雷原」になった話

導入

「既存の Python + Appium の成果物があるから、まず動かしてみて。動いたら同じPOM構成でテスト自動化ツールに反映して」 上司からの指示自体はシンプルでした。

Python の文法は知っています。 しかし、普段業務では使っていないため、手元に Python 環境はありません。 pip install から始めればいいだけだろう、と軽い気持ちでターミナルを開きました。

この時点では、そこから半日が消えるとは思っていませんでした。

第1章 私の「検証用PC」の中身

当時、テスト自動化担当だった私の検証用PCには、複数の自動化ツールが同居していました。

・Eggplant
・Katalon
・akaAT

検証対象のテスト自動化ツールを「まずライセンスに問題ないか確認しよう」と愚直にインストールしていきます。 気づいたときには、システム全体がツールとランタイムの闇鍋になっていました。

第2章 牙を剥く JAVA_HOME 上書き合戦

問題は、ツールごとに要求する Java（JDK）のバージョンが違うことでした。

例：Katalon は内蔵の Java 21、Appium 側は Java 17 を使う
新しいツールを入れる／動かすたびに、JAVA_HOME と PATH の書き換えが発生する

結果、「昨日まで起動していた業務アプリや別ツールが、あるツールのために環境変数を変えたら起動しなくなる」 という事故が起きます。 あっちを立てればこっちが立たず。

「venvを使用せずに Python 環境を足す」という行為を省略したのが間違いでした。

この検証でいちばん時間を取られたのは、あるツールを入れた状態から、RemoteTestKit を問題なく起動できる状態にたどり着くまででした。目的は、テスト自動化ツールで用意したプログラムから RemoteTestKit 上のレンタル端末を制御することです。その入口である RemoteTestKit の起動が、環境の組み合わせによってはすんなりいかないことがありました。有識者に相談すると、同じような状況に行き当たった例が過去にもあったと分かり、原因を深追いするよりも「起動までの手順を整えて社内ノウハウとして残そう」と考えました。

自分だけじゃなかった… とホッとした反面、 「対策を準備して社内ノウハウとして共有しよう」というやる気が湧いてきました。

第3章 「環境パズル」を解くために働いているわけじゃない

試したいのはサンプルコードのロジックなのに、その手前の環境構築というパズルで時間が溶けていきます。 この理不尽さを体験して、「100人がやって100人が同じ結果になる（再現性100%）」ことの価値を改めて痛感しました。

グローバルな環境変数を汚す限り、この地雷は踏み続けます。
対策としては、汚さずに隔離する方向へ切り替えるしかありません。

第4章 解決策：.venv や setlocal で「その場だけ」の砂場を作る

Docker を持ち出すほど大掛かりではありません。でも PC 全体の環境変数は汚したくありません。 そんなときに作ったのが、「このコマンドプロンプトの中でだけ、そのツール専用の環境に化けるバッチファイル」 でした。
まず自分用に作った版
最初に書いたのは、下記内容です。

@echo off
setlocal
:: 仮想環境を有効にする
call .venv\Scripts\activate
:: Java 等の設定
set JAVA_HOME=C:\Program Files\Java\jdk-17
set PATH=%JAVA_HOME%\bin;%PATH%
echo === Cloud Test Environment Ready ===
echo Pythonの仮想環境を読み込みました。
cmd /k

内容としては、.venv を有効化し、JAVA_HOME と PATH をこのバッチが開いている間だけ設定しています。 ダブルクリックすれば「Appium 用の砂場」が一発で立ち上がるので、自分の環境では、これで十分に機能していました。

「配る側」になって気づいた穴

ところが、これを社内ノウハウとして共有したい、つまり「自分以外の誰かが使用する」と考えた途端、このバッチの穴が見えてきました。

JDK のパスは人によって異なる。C:\Program Files\Java\jdk-17 は私の環境の値でしかありません。配布先やバージョンが違えば一致しないのに、書き換える場所がコメントからは読み取りづらいのです。
失敗しても素通りする。.venv が無くても、JAVA_HOME が違っても、バッチは止まらずに === Ready === と表示してしまいます。「準備OKと出たのに動かない」、この記事の冒頭で私自身が味わった絶望です。
「Ready」が口約束にすぎない。本当に Java と Python が使える状態なのか、表示からは確かめられません。

「100人がやって100人が同じ結果になる」を掲げておきながら、配るスクリプトが環境依存＆無検証では筋が通りません。そこで、配る前提で作り直しました。

配る前提で作り直した版

@echo off
setlocal
:: このバッチの場所を基準にする（どこから起動しても .venv を見つける）
cd /d "%~dp0"

:: ★環境に合わせて、この1行だけ書き換えてください
set JAVA_HOME=C:\Program Files\Java\jdk-17

:: --- 事前チェック（ここで転ばせて、無言の失敗を防ぐ）---
if not exist ".venv\Scripts\activate.bat" (
  echo [NG] .venv が見つかりません。先に python -m venv .venv を実行してください。
  pause & exit /b 1
)
if not exist "%JAVA_HOME%\bin\java.exe" (
  echo [NG] JAVA_HOME が正しくありません: %JAVA_HOME%
  pause & exit /b 1
)

call .venv\Scripts\activate
set PATH=%JAVA_HOME%\bin;%PATH%

:: --- 「準備OK」を視覚化 ---
echo === Cloud Test Environment Ready ===
java -version
python --version
cmd /k

このバッチには、3つの工夫を入れています。

書き換えるのは JAVA_HOME の1行だけ。 編集する場所を極限まで減らすことで、読み手が迷ったり間違えたりする余地を消します。

.venv と JDK の存在チェックで、無言の失敗を潰す。 パスが違えばその場で止めて理由を告げます。 「準備OKと表示されたのに実は動かない」という、この記事の冒頭で味わったのと同じ絶望を、自分のスクリプトからは生ませません。

最後に java -version と python --version を表示して、準備できたことを事実で見せる。 「Ready」という表示だけでなく、実際のバージョンで裏を取ります。

.venv で Python の依存を隔離し、環境変数の書き換えをこのシェルの中に閉じ込めることで、Appium 用の環境を「その場だけの砂場」に収められます。

「Docker ほど本格的でなくても、ダブルクリック一発で自分専用の安全な砂場を用意する」
地雷原の検証用PCで生き残るための、私なりの最適解でした。

まとめ

1台のPCに複数の自動化ツールを入れると、Java バージョン差で JAVA_HOME が競合し、環境全体が不安定になる
グローバル環境変数を汚さないことが鍵。.venv（Python 隔離）＋ シェル内だけの set で「その場だけの砂場」を作れる。「自分用に動く」と「誰に配っても動く」は別物。存在チェックとバージョン表示を足すだけで、無言の失敗を潰し「再現性100%」に一歩近づく
本格化するなら Docker で作り直せる環境へ。だが、まず一歩目としてこのバッチは軽くて強い

サンプルコードやドキュメントを書く側に回ってからは、「読者に同じ地雷を踏ませない」ことに執着するようになりました。それは別の記事で。