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 استعمال کر سکتا ہے۔ اس انتخاب کو ٹیسٹ کے مقصد میں نظر آتا رکھیں: کلائنٹ راستہ جانچنا اور آپریٹنگ سسٹم کی پراکسی دریافت جانچنا مختلف جانچیں ہیں۔