Dlaczego testy Javy nie widzą java.net.useSystemProxies
Przekazuj wrażliwe na start opcje wykrywania proxy w Javie do JVM uruchamiającego testy, a nie tylko do aplikacji lub launchera kompilacji.
Twoja aplikacja wykrywa proxy systemowe, ale test JUnit już nie. Zanim zmienisz kod wykrywania, ustal, który JVM uruchamia każdy proces i jakie argumenty otrzymał.
JDK dokumentuje java.net.useSystemProxies jako właściwość sprawdzaną raz przy starcie. Ustawienie jej wewnątrz metody testowej może być zbyt późne, aby zmienić tę decyzję startową.
Launcher aplikacji w IDE, runner testów IDE, sam Maven i rozwidlony proces testów Surefire mogą mieć różne argumenty VM. Ustawienie proxy w jednym launcherze nie jest dowodem, że inny launcher je przekazał.
Sprawdź konfigurację rozwidlonego procesu
argLine Surefire dostarcza opcje JVM wiersza poleceń dla rozwidlonych wykonań. Opcja startowa może tam należeć, gdy testy działają w takim rozwidleniu:
<argLine>-Djava.net.useSystemProxies=true</argLine>Scal opcję z istniejącą konfiguracją projektu. Zastąpienie istniejącego argLine może odrzucić agentów pokrycia lub inne wymagane ustawienia JVM. Jeśli kompilacja nie używa rozwidlenia, sprawdź zamiast tego JVM, który faktycznie hostuje testy; argLine jest udokumentowany jako skuteczny tylko dla rozwidlonych wykonań.
Właściwość niewrażliwa na start, dostarczana przez mechanizm właściwości frameworka testowego, ma inny cykl życia. Nie zakładaj, że każda właściwość dociera do VM wystarczająco wcześnie tylko dlatego, że System.getProperty() zwraca żądany ciąg podczas testu.
W przypadku skoncentrowanego testu routingu proxy jawnie skonfigurowany klient może również zmniejszyć zależność od konfiguracji pulpitu. Java 11+ HttpClient może w tym celu użyć lokalnego dla klienta HTTP ProxySelector. Utrzymuj ten wybór widocznym w zamiarze testu: testowanie trasy klienta i testowanie wykrywania proxy przez system operacyjny to różne kontrole.