Pse testet Java nuk e shohin java.net.useSystemProxies

Aplikacioni juaj e zbulon proxy-n e sistemit, por një test JUnit jo. Përpara se të ndryshoni kodin e zbulimit, përcaktoni cili JVM ekzekuton çdo proces dhe çfarë argumentesh ka marrë.

JDK dokumenton java.net.useSystemProxies si një veti që kontrollohet një herë në nisje. Vendosja e saj brenda një metode testi mund të jetë tepër vonë për të ndryshuar atë vendim nisjeje.

Nisësi i aplikacionit në IDE, ekzekutuesi i testeve në IDE, vetë Maven dhe një proces testesh Surefire i degëzuar mund të kenë të gjithë argumente VM të ndryshme. Një rregullim proxy në një nisës nuk është provë që një nisës tjetër e ka kaluar atë.

Kontrolloni konfigurimin e procesit të degëzuar

argLine i Surefire ofron opsione JVM nga rreshti i komandës për ekzekutimet e degëzuara. Një opsion nisjeje mund t'i përkasë atje kur testet ekzekutohen në një degëzim të tillë:

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

Bashkoni opsionin me konfigurimin ekzistues të projektit. Zëvendësimi i një argLine ekzistues mund të hedhë poshtë agjentë mbulimi ose rregullime të tjera të nevojshme të JVM. Nëse ndërtimi nuk përdor asnjë degëzim, inspektoni në vend të tij JVM që strehon vërtet testet; argLine dokumentohet si efektiv vetëm për ekzekutimet e degëzuara.

Një veti që nuk varet nga nisja dhe jepet përmes mekanizmit të vetive të një kornize testimi ka një cikël jetësor tjetër. Mos supozoni se çdo veti arrin te VM mjaft herët vetëm sepse System.getProperty() kthen vargun e dëshiruar gjatë testit.

Për një test të fokusuar të rrugëtimit përmes proxy-t, një klient i konfiguruar shprehimisht mund të zvogëlojë gjithashtu varësinë nga konfigurimi i desktopit. Java 11+ HttpClient mund të përdorë për këtë një HTTP ProxySelector lokal për klientin. Mbajeni atë zgjedhje të dukshme në qëllimin e testit: testimi i një rruge klienti dhe testimi i zbulimit të proxy-t të sistemit operativ janë kontrolle të ndryshme.