Kvifor Java-testar overser java.net.useSystemProxies
Send oppstartsfølsame Java-proxyoppdagingsval til JVM-en som køyrer testane, ikkje berre til applikasjonen eller byggjestartaren.
Applikasjonen din oppdagar systemproxien, men ein JUnit-test gjer det ikkje. Før du endrar oppdagingskoden, må du finne ut kva JVM som køyrer kvar prosess og kva argument han fekk.
JDK-en dokumenterer java.net.useSystemProxies som ein eigenskap som blir kontrollert éin gong ved oppstart. Å setje han inne i ein testmetode kan vere for seint til å endre den oppstartsavgjerda.
Ein IDE-applikasjonsstartar, ein IDE-testkøyrar, sjølve Maven og ein forgreina Surefire-testprosess kan alle ha ulike VM-argument. Ei proxyinnstilling i ein startar er ikkje prov på at ein annan startar sende henne vidare.
Kontroller konfigurasjonen til den forgreina prosessen
Surefires argLine leverer JVM-kommandolinjeval for forgreina køyringar. Eit oppstartsval kan høyre heime der når testane køyrer i ei slik forgreining:
<argLine>-Djava.net.useSystemProxies=true</argLine>Flett valet inn i den eksisterande konfigurasjonen til prosjektet. Å erstatte ein eksisterande argLine kan kaste dekningsagentar eller andre nødvendige JVM-innstillingar. Viss bygget ikkje brukar noka forgreining, undersøk i staden JVM-en som faktisk er vert for testane; argLine er dokumentert som effektiv berre for forgreina køyringar.
Ein eigenskap som ikkje er oppstartsfølsam og blir levert via eigensskapsmekanismen til eit testrammeverk, har ein annan livssyklus. Ikkje gå ut frå at kvar eigenskap når VM-en tidleg nok berre fordi System.getProperty() returnerer den ønskte strengen under testen.
For ein målretta proxy-rutingstest kan ein eksplisitt konfigurert klient òg redusere avhengnaden av skrivebordskonfigurasjon. Java 11+ HttpClient kan bruke ein klientlokal HTTP ProxySelector til dette føremålet. Hald det valet synleg i hensikta til testen: å teste ei klientrute og å teste oppdaging av operativsystemproxien er forskjellige kontrollar.