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 वापरू शकतो. ती निवड चाचणीच्या हेतूत दृश्यमान ठेवा: क्लायंट मार्ग तपासणे आणि ऑपरेटिंग सिस्टमची प्रॉक्सी शोध तपासणे या वेगवेगळ्या तपासण्या आहेत.