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를 사용할 수 있습니다. 그 선택을 테스트의 의도에 드러내 두세요. 클라이언트 경로를 테스트하는 것과 운영 체제의 프록시 검색을 테스트하는 것은 다른 확인입니다.