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 ફક્ત ફોર્ક કરેલી એક્ઝિક્યુશન માટે જ અસરકારક હોવાનું દસ્તાવેજ છે.

ટેસ્ટ ફ્રેમવર્કની પ્રોપર્ટી મિકેનિઝમ દ્વારા પૂરી પાડવામાં આવતી સ્ટાર્ટઅપ-સંવેદનશીલ ન હોય તેવી પ્રોપર્ટીનું જીવનચક્ર અલગ હોય છે. ફક્ત એટલા માટે ધારશો નહીં કે દરેક પ્રોપર્ટી VM સુધી પૂરતા સમય પહેલાં પહોંચે છે કારણ કે System.getProperty() ટેસ્ટ દરમિયાન ઇચ્છિત સ્ટ્રિંગ પરત કરે છે.

કેન્દ્રિત પ્રોક્સી-રાઉટિંગ ટેસ્ટ માટે, સ્પષ્ટ રીતે ગોઠવાયેલ ક્લાયન્ટ ડેસ્કટોપ ગોઠવણી પરની નિર્ભરતા પણ ઘટાડી શકે. Java 11+ HttpClient તે હેતુ માટે ક્લાયન્ટ-સ્થાનિક HTTP ProxySelector વાપરી શકે. તે પસંદગીને ટેસ્ટના ઉદ્દેશમાં દૃશ્યમાન રાખો: ક્લાયન્ટ રૂટ ટેસ્ટ કરવો અને ઓપરેટિંગ સિસ્ટમની પ્રોક્સી શોધ ટેસ્ટ કરવી અલગ અલગ તપાસ છે.