Hvorfor Java-tester overser java.net.useSystemProxies
Send oppstartsfølsomme Java-proxyoppdagelsesvalg til JVM-en som kjører testene, ikke bare til applikasjonen eller byggestarteren.
Applikasjonen din oppdager systemproxien, men en JUnit-test gjør det ikke. Før du endrer oppdagelseskoden, må du finne ut hvilken JVM som kjører hver prosess og hvilke argumenter den fikk.
JDK-en dokumenterer java.net.useSystemProxies som en egenskap som kontrolleres én gang ved oppstart. Å sette den inne i en testmetode kan være for sent til å endre den oppstartsbeslutningen.
En IDE-applikasjonsstarter, en IDE-testkjører, selve Maven og en forgrenet Surefire-testprosess kan alle ha ulike VM-argumenter. En proxyinnstilling i én starter er ikke bevis for at en annen starter sendte den videre.
Kontroller konfigurasjonen til den forgrenede prosessen
Surefires argLine leverer JVM-kommandolinjevalg for forgrenede kjøringer. Et oppstartsvalg kan høre hjemme der når testene kjører i en slik forgrening:
<argLine>-Djava.net.useSystemProxies=true</argLine>Flett valget inn i prosjektets eksisterende konfigurasjon. Å erstatte en eksisterende argLine kan kaste dekningsagenter eller andre nødvendige JVM-innstillinger. Hvis bygget ikke bruker noen forgrening, undersøk i stedet JVM-en som faktisk er vert for testene; argLine er dokumentert som effektiv bare for forgrenede kjøringer.
En egenskap som ikke er oppstartsfølsom og leveres via et testrammeverks egenskapsmekanisme, har en annen livssyklus. Ikke anta at hver egenskap når VM-en tidlig nok bare fordi System.getProperty() returnerer den ønskede strengen under testen.
For en målrettet proxy-rutingstest kan en eksplisitt konfigurert klient også redusere avhengigheten av skrivebordskonfigurasjon. Java 11+ HttpClient kan bruke en klientlokal HTTP ProxySelector til dette formålet. Hold det valget synlig i testens hensikt: å teste en klientrute og å teste oppdagelse av operativsystemets proxy er forskjellige kontroller.