Hvers vegna Java-próf ná ekki java.net.useSystemProxies

Forritið þitt greinir kerfismilliþjóninn, en JUnit-próf gerir það ekki. Áður en þú breytir greiningarkóðanum skaltu ákvarða hvaða JVM keyrir hvert ferli og hvaða rök það fékk.

JDK skjalfestir java.net.useSystemProxies sem eiginleika sem er athugaður einu sinni við upphaf. Að setja hann inni í prófaðferð getur verið of seint til að breyta þeirri upphafsákvörðun.

Upphafsforrit IDE, prófkeyrir IDE, Maven sjálft og greind Surefire-prófferli geta öll haft mismunandi VM-rök. Milliþjónsstilling í einum upphafsforriti er ekki sönnun þess að annað upphafsforrit hafi sent hana áfram.

Athugaðu uppsetningu greinda ferlisins

argLine Surefire veitir JVM-valkosti á skipanalínu fyrir greindar keyrslur. Upphafsvalkostur getur átt heima þar þegar prófin keyra í slíkri grein:

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

Sameinaðu valkostinn við fyrirliggjandi uppsetningu verkefnisins. Að skipta út fyrirliggjandi argLine getur hent út þekjuumboðum eða öðrum nauðsynlegum JVM-stillingum. Ef byggingin notar enga grein skaltu skoða JVM-ið sem hýsir prófin í raun í staðinn; argLine er skjalfest sem virkt aðeins fyrir greindar keyrslur.

Eiginleiki sem er ekki upphafsnæmur og er veittur gegnum eiginleikakerfi prófaramna hefur annan lífsferil. Ekki gera ráð fyrir að hver eiginleiki nái VM-inu nógu snemma bara vegna þess að System.getProperty() skilar tilætluðu strengnum meðan á prófinu stendur.

Fyrir einbeitt próf á milliþjónsleiðingu getur skýrt uppsettur biðlari líka dregið úr háð skrifborðsuppsetningarinnar. Java 11+ HttpClient getur notað HTTP ProxySelector staðbundið biðlaranum í þeim tilgangi. Haltu þeirri ákvörðun sýnilegri í tilgangi prófsins: að prófa biðlaraleið og að prófa uppgötvun milliþjóns stýrikerfisins eru mismunandi athuganir.