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 उपयोग कर सकता है। उस चयन को टेस्ट के इरादे में दिखाई देने वाला रखें: क्लाइंट रूट जाँचना और ऑपरेटिंग सिस्टम की प्रॉक्सी खोज जाँचना अलग-अलग जाँचें हैं।