Zakaj testi Jave zgrešijo java.net.useSystemProxies
Posredujte možnosti odkrivanja proxyja v Javi, občutljive na zagon, JVM, ki izvaja teste, ne le aplikaciji ali zaganjalniku gradnje.
Vaša aplikacija zazna sistemski proxy, test JUnit pa ne. Preden spremenite kodo za odkrivanje, ugotovite, kateri JVM izvaja vsak proces in katere argumente je prejel.
JDK dokumentira java.net.useSystemProxies kot lastnost, ki se preveri enkrat ob zagonu. Nastavitev znotraj testne metode je lahko prepozno za spremembo te odločitve ob zagonu.
Zaganjalnik aplikacije v IDE, izvajalnik testov IDE, sam Maven in razvejeni testni proces Surefire imajo lahko različne argumente VM. Nastavitev proxyja v enem zaganjalniku ni dokaz, da jo je drugi zaganjalnik posredoval.
Preverite konfiguracijo razvejenega procesa
argLine v Surefire zagotavlja JVM možnosti ukazne vrstice za razvejene izvedbe. Možnost zagona lahko spada tja, ko testi tečejo v taki razvejitvi:
<argLine>-Djava.net.useSystemProxies=true</argLine>Združite možnost z obstoječo konfiguracijo projekta. Zamenjava obstoječega argLine lahko zavrže agente pokritosti ali druge potrebne nastavitve JVM. Če gradnja ne uporablja razvejitve, namesto tega preglejte JVM, ki dejansko gosti teste; argLine je dokumentiran kot učinkovit samo za razvejene izvedbe.
Lastnost, ki ni občutljiva na zagon in je zagotovljena prek mehanizma lastnosti testnega ogrodja, ima drugačen življenjski cikel. Ne predpostavljajte, da vsaka lastnost doseže VM dovolj zgodaj samo zato, ker System.getProperty() med testom vrne želeni niz.
Za osredotočen test usmerjanja proxyja lahko izrecno konfiguriran odjemalec tudi zmanjša odvisnost od konfiguracije namizja. Java 11+ HttpClient lahko v ta namen uporabi HTTP ProxySelector, lokalni za odjemalca. Naj bo ta izbira vidna v namenu testa: preizkušanje odjemalčeve poti in preizkušanje odkrivanja proxyja operacijskega sistema sta različni preverjanji.