Java testləri java.net.useSystemProxies-i niyə görmür
Başlanğıca həssas Java proksi aşkarlama seçimlərini yalnız tətbiqə və ya build işəsalana deyil, testləri işlədən JVM-ə ötürün.
Tətbiqiniz sistem proksisini aşkarlayır, amma JUnit testi aşkarlamır. Aşkarlama kodunu dəyişməzdən əvvəl hansı JVM-in hər prosesi işlətdiyini və hansı arqumentləri aldığını müəyyən edin.
JDK java.net.useSystemProxies xassəsini başlanğıcda bir dəfə yoxlanılan xassə kimi sənədləşdirir. Onu test metodunun içində təyin etmək həmin başlanğıc qərarını dəyişmək üçün çox gec ola bilər.
IDE tətbiq işəsalani, IDE test runneri, Maven özü və fork edilmiş Surefire test prosesi fərqli VM arqumentlərinə malik ola bilər. Bir işəsalanda edilən proksi tənzimi başqa işəsalının onu ötürdüyünə sübut deyil.
Fork edilmiş proses konfiqurasiyasını yoxlayın
Surefire-in argLine fork edilmiş icralar üçün əmr sətri JVM seçimləri təqdim edir. Testlər belə bir forkda işləyəndə başlanğıc seçimi orada yerləşə bilər:
<argLine>-Djava.net.useSystemProxies=true</argLine>Seçimi layihənin mövcud konfiqurasiyasına birləşdirin. Mövcud argLine-ı dəyişdirmək coverage agentlərini və ya digər tələb olunan JVM tənzimlərini itirə bilər. Build fork istifadə etmirsə, bunun əvəzinə testləri həqiqətən host edən JVM-i yoxlayın; argLine yalnız fork edilmiş icralar üçün effektiv kimi sənədləşdirilib.
Test çərçivəsinin xassə mexanizmi ilə verilən başlanğıca həssas olmayan xassənin fərqli həyat dövrü var. Sadəcə System.getProperty() test zamanı istənilən sətri qaytardığı üçün hər xassənin VM-ə kifayət qədər erkən çatdığını güman etməyin.
Fokuslanmış proksi-marşrut testi üçün açıq şəkildə konfiqurasiya edilmiş klient masaüstü konfiqurasiyasından asılılığı da azalda bilər. Java 11+ HttpClient bu məqsədlə klientdaxili HTTP ProxySelector istifadə edə bilər. Bu seçimi testin niyyətində görünən saxlayın: klient marşrutunu test etmək və əməliyyat sistemi proksi aşkarlamasını test etmək fərqli yoxlamalardır.