Hvorfor Java-test ikke fanger java.net.useSystemProxies
Send opstartsfølsomme Java-proxyopdagelsesindstillinger til den JVM, der kører testene, ikke kun til applikationen eller build-starteren.
Din applikation registrerer systemproxyen, men en JUnit-test gør ikke. Før du ændrer registreringskoden, skal du afgøre, hvilken JVM der kører hver proces, og hvilke argumenter den har fået.
JDK'en dokumenterer java.net.useSystemProxies som en egenskab, der kontrolleres én gang ved opstart. At sætte den inde i en testmetode kan være for sent til at ændre den opstartsbeslutning.
En IDE-applikationsstarter, en IDE-testrunner, selve Maven og en forgrenet Surefire-testproces kan alle have forskellige VM-argumenter. En proxyindstilling i én starter er ikke bevis for, at en anden starter har videresendt den.
Kontroller konfigurationen af den forgrenede proces
Surefires argLine leverer JVM-kommandolinjeindstillinger til forgrenede kørsler. En opstartsindstilling kan høre hjemme der, når testene kører i en sådan forgrening:
<argLine>-Djava.net.useSystemProxies=true</argLine>Flet indstillingen ind i projektets eksisterende konfiguration. Udskiftning af en eksisterende argLine kan kaste dækningsagenter eller andre nødvendige JVM-indstillinger væk. Hvis buildet ikke bruger nogen forgrening, skal du i stedet undersøge den JVM, der faktisk hoster testene; argLine er dokumenteret som effektiv kun for forgrenede kørsler.
En egenskab, der ikke er opstartsfølsom, og som leveres via et testframeworks egenskabsmekanisme, har en anden livscyklus. Antag ikke, at hver egenskab når VM'en tidligt nok, blot fordi System.getProperty() returnerer den ønskede streng under testen.
Til en målrettet proxy-routingtest kan en eksplicit konfigureret klient også mindske afhængigheden af skrivebordskonfiguration. Java 11+ HttpClient kan bruge en klientlokal HTTP ProxySelector til det formål. Hold det valg synligt i testens hensigt: at teste en klientrute og at teste opdagelse af operativsystemets proxy er forskellige kontroller.