কেন 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 ব্যবহার করতে পারে। এই পছন্দটি টেস্টের উদ্দেশ্যে দৃশ্যমান রাখুন: ক্লায়েন্ট রুট পরীক্ষা করা এবং অপারেটিং সিস্টেমের প্রক্সি ডিসকভারি পরীক্ষা করা ভিন্ন ভিন্ন যাচাই।