چرا تست‌های Java ویژگی java.net.useSystemProxies را از دست می‌دهند
گزینه‌های کشف پروکسی Java که به راه‌اندازی حساس‌اند را به JVM اجراکننده تست‌ها بدهید، نه فقط به برنامه یا راه‌انداز ساخت.
برنامه شما پروکسی سیستم را تشخیص می‌دهد، اما یک تست JUnit این کار را نمی‌کند. پیش از تغییر کد تشخیص، مشخص کنید کدام JVM هر فرایند را اجرا می‌کند و چه آرگومان‌هایی دریافت کرده است.
JDK ویژگی java.net.useSystemProxies را خاصیتی مستند می‌کند که یک بار در هنگام راه‌اندازی بررسی می‌شود. تنظیم آن درون یک متد تست می‌تواند برای تغییر آن تصمیم راه‌اندازی بسیار دیر باشد.
یک راه‌انداز برنامه IDE، یک اجراکننده تست IDE، خود Maven و یک فرایند تست Surefire منشعب‌شده می‌توانند آرگومان‌های VM متفاوتی داشته باشند. تنظیم پروکسی در یک راه‌انداز دلیل بر آن نیست که راه‌انداز دیگری آن را منتقل کرده است.
پیکربندی فرایند منشعب‌شده را بررسی کنید
argLine در Surefire گزینه‌های JVM خط فرمان را برای اجراهای منشعب‌شده فراهم می‌کند. گزینه راه‌اندازی می‌تواند وقتی تست‌ها در چنین انشعابی اجرا می‌شوند، آنجا باشد:
<argLine>-Djava.net.useSystemProxies=true</argLine>گزینه را با پیکربندی موجود پروژه ادغام کنید. جایگزینی argLine موجود می‌تواند عامل‌های پوشش یا دیگر تنظیمات لازم JVM را دور بریزد. اگر ساخت از هیچ انشعابی استفاده نمی‌کند، به‌جای آن JVM را که واقعاً میزبان تست‌هاست بررسی کنید؛ argLine مستند شده است که فقط برای اجراهای منشعب‌شده مؤثر است.
خاصیتی که به راه‌اندازی حساس نیست و از طریق سازوکار خاصیت‌های یک چارچوب تست تأمین می‌شود، چرخه عمر متفاوتی دارد. فرض نکنید هر خاصیت فقط به این دلیل که System.getProperty() در طول تست رشته موردنظر را برمی‌گرداند، به‌اندازه کافی زود به VM می‌رسد.
برای یک تست مسیریابی پروکسی متمرکز، یک کلاینت صراحتاً پیکربندی‌شده نیز می‌تواند وابستگی به پیکربندی میزکار را کاهش دهد. Java 11+ HttpClient می‌تواند برای این منظور از یک HTTP ProxySelector محلی کلاینت استفاده کند. این انتخاب را در قصد تست قابل مشاهده نگه دارید: آزمودن یک مسیر کلاینت و آزمودن کشف پروکسی سیستم‌عامل دو بررسی متفاوت‌اند.