لماذا تفوت اختبارات 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 موثّق بأنه فعّال فقط للتنفيذات المتفرعة.
للخاصية غير الحساسة لبدء التشغيل التي تُقدَّم عبر آلية خصائص إطار الاختبار دورة حياة مختلفة. تجنّب افتراض أن كل خاصية تصل إلى VM مبكرًا بما يكفي لمجرد أن System.getProperty() يعيد السلسلة المطلوبة أثناء الاختبار.
لاختبار توجيه وكيل مركّز، يمكن لعميل مُهيَّأ صراحةً أن يقلّل أيضًا الاعتماد على إعداد سطح المكتب. يستطيع Java 11+ HttpClient استخدام ProxySelector HTTP محلي للعميل لذلك الغرض. أبقِ هذا الاختيار ظاهرًا في مقصد الاختبار: اختبار مسار العميل واختبار اكتشاف وكيل نظام التشغيل فحصان مختلفان.