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 ਵਰਤ ਸਕਦਾ ਹੈ। ਉਸ ਚੋਣ ਨੂੰ ਟੈਸਟ ਦੇ ਇਰਾਦੇ ਵਿੱਚ ਦਿਸਦਾ ਰੱਖੋ: ਕਲਾਇੰਟ ਰੂਟ ਜਾਂਚਣਾ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਪ੍ਰੌਕਸੀ ਖੋਜ ਜਾਂਚਣਾ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਹਨ।