ولې د Java ازموینې java.net.useSystemProxies له لاسه ورکوي
د Java د پروکسي موندنې هغه انتخابونه چې په پیل پورې تړلي دي، هغه JVM ته وسپارئ چې ازموینې چلوي، نه یوازې اپلیکیشن یا د build پیل کوونکي ته.
ستاسو اپلیکیشن د سیستم پروکسي پېژني، خو د JUnit ازموینه یې نه پېژني. مخکې له دې چې د موندنې کوډ بدل کړئ، معلومه کړئ کوم JVM هر بهیر چلوي او کوم دلیلونه یې ترلاسه کړي.
JDK java.net.useSystemProxies د یوې ځانګړنې په توګه ثبتوي چې د پیل پر مهال یوازې یو ځل کتل کیږي. په ازموینه کې د هغې ټاکل ممکن د هغې پیلېدونکې پرېکړې د بدلولو لپاره ډېر ناوخته وي.
د IDE د اپلیکیشن پیل کوونکی، د IDE د ازموینې چلوونکی، Maven پخپله او د Surefire یو څانګه شوی ازموینه بهیر ټول کولای شي بېلابېل VM دلیلونه ولري. په یو پیل کوونکي کې د پروکسي ترتیبات د دې ثبوت نه دي چې بل پیل کوونکی یې لېږلی وي.
د څانګه شوي بهیر ترتیبات وګورئ
د Surefire argLine د څانګه شوو اجرااتو لپاره د کرښې JVM انتخابونه برابروي. کله چې ازموینې په داسې څانګه کې چلیږي، د پیل انتخاب کولای شي هلته وي:
<argLine>-Djava.net.useSystemProxies=true</argLine>انتخاب د پروژې موجود ترتیباتو سره یوځای کړئ. د موجود argLine بدلول کولای شي د پوښښ استازي یا نور اړین JVM ترتیبات له لاسه ورکړي. که build کومه څانګه نه کاروي، پرځای یې هغه JVM وګورئ چې واقعاً ازموینې کوربه کوي؛ argLine یوازې د څانګه شوو اجرااتو لپاره اغېزمن ثبت شوی.
هغه ځانګړنه چې په پیل پورې تړلې نه ده او د ازموینې چوکاټ د ځانګړنو له لارې وړاندې کیږي، بېلابېل ژوند لري. دا مه انګېرئ چې هر ځانګړنه VM ته په کافي وخت رسېږي یوازې ځکه چې System.getProperty() د ازموینې پر مهال غوښتل شوې تار بېرته راګرځوي.
د یوې متمرکزې پروکسي لارې ازموینې لپاره، په څرګنده توګه ترتیب شوی کلاینت کولای شي پر ډیسکټاپ ترتیباتو تکیه هم کمه کړي. Java 11+ HttpClient کولای شي د دې هدف لپاره د کلاینت دننه HTTP ProxySelector وکاروي. هغه انتخاب د ازموینې په نیت کې څرګند وساتئ: د کلاینت لارې ازموینه او د عملیاتي سیستم د پروکسي موندنې ازموینه بېلابېلې کتنې دي.