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 फोर्क गरिएका कार्यान्वयनका लागि मात्र प्रभावकारी भएको अभिलेख छ।

परीक्षण फ्रेमवर्कको गुण संयन्त्रबाट दिइने स्टार्टअप-संवेदनशील नभएको गुणको जीवनचक्र फरक हुन्छ। परीक्षणका क्रममा System.getProperty() ले इच्छित स्ट्रिङ फर्काउँछ भन्ने मात्र कारणले प्रत्येक गुण VM सम्म पर्याप्त चाँडो पुग्छ भनी नमान्नुहोस्।

केन्द्रित प्रोक्सी-राउटिङ परीक्षणका लागि, स्पष्ट रूपमा कन्फिगर गरिएको क्लाइन्टले डेस्कटप कन्फिगरेसनमाथिको निर्भरता पनि घटाउन सक्छ। Java 11+ HttpClient ले त्यसका लागि क्लाइन्ट-स्थानीय HTTP ProxySelector प्रयोग गर्न सक्छ। त्यो छनोट परीक्षणको मनसायमा देखिने राख्नुहोस्: क्लाइन्ट मार्ग जाँच्नु र अपरेटिङ सिस्टमको प्रोक्सी पत्ता लगाउने कार्य जाँच्नु फरक जाँच हुन्।