Varför Java-tester missar java.net.useSystemProxies
Skicka startkänsliga Java-proxyidentifieringsalternativ till JVM:en som kör testerna, inte bara till applikationen eller byggstartaren.
Din applikation identifierar systemproxyn, men ett JUnit-test gör det inte. Innan du ändrar identifieringskoden, ta reda på vilken JVM som kör varje process och vilka argument den fick.
JDK:n dokumenterar java.net.useSystemProxies som en egenskap som kontrolleras en gång vid start. Att sätta den inuti en testmetod kan vara för sent för att ändra det startbeslutet.
En IDE-applikationsstartare, en IDE-testkörning, Maven självt och en forgrenad Surefire-testprocess kan alla ha olika VM-argument. En proxyinställning i en startare är inte bevis för att en annan startare skickade vidare den.
Kontrollera konfigurationen för den forgrenade processen
Surefires argLine tillhandahåller JVM-kommandoradsalternativ för forgrenade körningar. Ett startalternativ kan höra hemma där när testerna körs i en sådan forgrening:
<argLine>-Djava.net.useSystemProxies=true</argLine>Slå samman alternativet med projektets befintliga konfiguration. Att ersätta en befintlig argLine kan kasta bort täckningsagenter eller andra nödvändiga JVM-inställningar. Om bygget inte använder någon forgrening, undersök i stället den JVM som faktiskt är värd för testerna; argLine är dokumenterat som effektivt endast för forgrenade körningar.
En egenskap som inte är startkänslig och som tillhandahålls via ett testramverks egenskapsmekanism har en annan livscykel. Anta inte att varje egenskap når JVM:en tidigt nog bara för att System.getProperty() returnerar den önskade strängen under testet.
För ett fokuserat proxy-routingtest kan en explicit konfigurerad klient också minska beroendet av skrivbordskonfiguration. Java 11+ HttpClient kan använda en klientlokal HTTP ProxySelector för det ändamålet. Håll det valet synligt i testets avsikt: att testa en klientväg och att testa operativsystemets proxyidentifiering är olika kontroller.