Hvorfor Java-tester ikke oppdager java.net.useSystemProxies
Videreformidl oppstartsfølsomme Java-proxyoppdagelsesvalg til JVM-en som kjører testene, ikke bare til applikasjonen eller byggstarteren.
Applikasjonen din oppdager systemproxien, men en JUnit-test gjør det ikke. Før du endrer oppdagelseskoden, må du avgjøre 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 for å endre den oppstartsbeslutningen.
En IDE-applikasjonsstarter, en IDE-testkjører, Maven selv og en forgrenet Surefire-testprosess kan alle ha forskjellige VM-argumenter. En proxyinnstilling i én starter er ikke bevis for at en annen starter sendte den videre.
Kontroller konfigurasjonen av den forgrenede prosessen
Surefires argLine gir 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.