Чаму тэсты Java не бачаць java.net.useSystemProxies
Перадавайце залежныя ад запуску параметры выяўлення проксі Java у JVM, якая запускае тэсты, а не толькі ў праграму або запускальнік зборкі.
Ваша праграма вызначае сістэмны проксі, а тэст JUnit — не. Перш чым змяняць код выяўлення, вызначце, якая JVM запускае кожны працэс і якія аргументы яна атрымала.
JDK дакументуе java.net.useSystemProxies як уласцівасць, якая правяраецца адзін раз пры запуску. Заданне яе ўнутры метаду тэста можа быць занадта познім, каб змяніць гэтае рашэнне пры запуску.
Запускальнік праграмы IDE, запускальнік тэстаў IDE, сам Maven і адгалінаваны працэс тэстаў Surefire могуць мець розныя аргументы VM. Налада проксі ў адным запускальніку не з'яўляецца доказам таго, што іншы запускальнік перадаў яе.
Праверце канфігурацыю адгалінаванага працэсу
argLine у Surefire дае параметры JVM каманднага радка для адгалінаваных выкананняў. Параметр запуску можа знаходзіцца там, калі тэсты выконваюцца ў такім адгалінаванні:
<argLine>-Djava.net.useSystemProxies=true</argLine>Аб'яднайце параметр з існуючай канфігурацыяй праекта. Замена існуючага argLine можа адкінуць агенты пакрыцця або іншыя патрэбныя налады JVM. Калі зборка не выкарыстоўвае адгалінаванне, замест гэтага агледзьце JVM, якая фактычна абслугоўвае тэсты; argLine, як задокументавана, дзейнічае толькі для адгалінаваных выкананняў.
Уласцівасць, не залежная ад запуску, перададзеная праз механізм уласцівасцей тэставага фрэймворка, мае іншы жыццёвы цыкл. Не мяркуйце, што кожная ўласцівасць дасягае VM дастаткова рана толькі таму, што System.getProperty() вяртае патрэбны радок падчас тэста.
Для сфакусаванага тэста маршрутызацыі праз проксі явна наладжаны кліент таксама можа паменшыць залежнасць ад налад працоўнага стала. Java 11+ HttpClient можа выкарыстоўваць для гэтага лакальны для кліента HTTP ProxySelector. Трымайце гэты выбар бачным у мэце тэста: праверка маршруту кліента і праверка выяўлення проксі аперацыйнай сістэмы — гэта розныя праверкі.