Java testlari java.net.useSystemProxies-ni nega ko'rmaydi

Ilovangiz tizim proksisini aniqlaydi, lekin JUnit testi aniqlmaydi. Aniqlash kodini o'zgartirishdan oldin qaysi JVM har bir jarayonni bajarishini va qanday argumentlar olganini aniqlang.

JDK java.net.useSystemProxies ni ishga tushishda bir marta tekshiriladigan xususiyat sifatida hujjatlashtiradi. Uni test metodining ichida belgilash o'sha ishga tushish qarorini o'zgartirish uchun juda kech bo'lishi mumkin.

IDE ilova ishga tushirgichi, IDE test bajaruvchisi, Mavenning o'zi va shoxlangan Surefire test jarayoni har xil VM argumentlariga ega bo'lishi mumkin. Bitta ishga tushirgichdagi proksi sozlamasi boshqasi uni uzatganiga dalil emas.

Shoxlangan jarayon konfiguratsiyasini tekshiring

Surefire ning argLine shoxlangan bajarishlar uchun buyruq qatori JVM parametrlarini beradi. Testlar shunday shoxda ishlaganda ishga tushish parametri o'sha yerda bo'lishi mumkin:

<argLine>-Djava.net.useSystemProxies=true</argLine>

Parametrni loyihaning mavjud konfiguratsiyasiga birlashtiring. Mavjud argLine ni almashtirish qamrov agentlarini yoki boshqa zarur JVM sozlamalarini yo'qotishi mumkin. Agar build hech qanday shoxdan foydalanmasa, o'rniga testlarni haqiqatda joylashtirgan JVM ni tekshiring; argLine faqat shoxlangan bajarishlar uchun samarali deb hujjatlashtirilgan.

Test freymvorkining xususiyatlar mexanizmi orqali berilgan, ishga tushishga sezgir bo'lmagan xususiyatning hayot sikli boshqacha. Test davomida System.getProperty() kerakli satrni qaytaradi deb har bir xususiyat VM ga yetarlicha erta yetadi, deb o'ylamang.

Maqsadli proksi-marshrutlash testi uchun aniq sozlangan klient ish stoli konfiguratsiyasiga bog'liqlikni ham kamaytirishi mumkin. Java 11+ HttpClient buning uchun klient ichidagi HTTP ProxySelector dan foydalanishi mumkin. Bu tanlovni test maqsadida ko'rinadigan qilib saqlang: klient yo'lini sinash va operatsion tizim proksisini aniqlashni sinash har xil tekshiruvlar.