Java テストが java.net.useSystemProxies を見逃す理由

アプリケーションはシステムプロキシを検出しても、JUnit テストは検出しないことがあります。検出コードを変更する前に、どの JVM が各プロセスを実行し、どの引数を受け取ったのかを特定してください。

JDK は java.net.useSystemProxies を起動時に一度だけ確認されるプロパティとして文書化しています。テストメソッドの中で設定しても、その起動時の判断を変えるには遅すぎる可能性があります。

IDE のアプリケーション起動構成、IDE のテストランナー、Maven 自体、フォークされた Surefire のテストプロセスは、それぞれ異なる VM 引数を持ち得ます。ある起動構成のプロキシ設定は、別の起動構成がそれを渡した証拠にはなりません。

フォークされたプロセスの設定を確認する

Surefire の argLine は、フォーク実行に対するコマンドライン JVM オプションを提供します。テストがそのようなフォークで実行される場合、起動オプションはそこに属することがあります。

<argLine>-Djava.net.useSystemProxies=true</argLine>

オプションはプロジェクトの既存の設定に統合してください。既存の argLine を置き換えると、カバレッジエージェントやその他の必要な JVM 設定が失われる可能性があります。ビルドがフォークを使わない場合は、代わりに実際にテストをホストする JVM を確認してください。argLine はフォーク実行に対してのみ有効と文書化されています。

テストフレームワークのプロパティ機構で供給される、起動時に依存しないプロパティは、ライフサイクルが異なります。テスト中に System.getProperty() が目的の文字列を返すという理由だけで、すべてのプロパティが十分早く VM に届くと仮定しないでください。

的を絞ったプロキシ経路のテストでは、明示的に構成されたクライアントを使うことでデスクトップ設定への依存を減らせます。Java 11+ の HttpClient はそのためにクライアントローカルの HTTP ProxySelectorを利用できます。この選択はテストの意図の中で見えるようにしてください。クライアント経路をテストすることと、OS のプロキシ検出をテストすることは別の確認です。