Почему тесты Java не видят java.net.useSystemProxies

Ваше приложение определяет системный прокси, а тест JUnit — нет. Прежде чем менять код обнаружения, выясните, какая JVM запускает каждый процесс и какие аргументы она получила.

JDK документирует java.net.useSystemProxies как свойство, проверяемое один раз при запуске. Установка его внутри метода теста может оказаться слишком поздней, чтобы изменить это решение при запуске.

Лаунчер приложения в IDE, средство запуска тестов IDE, сам Maven и ответвлённый процесс тестов Surefire могут иметь разные аргументы VM. Настройка прокси в одном лаунчере не доказывает, что другой лаунчер её передал.

Проверьте конфигурацию ответвлённого процесса

argLine в Surefire задаёт параметры JVM командной строки для ответвлённых запусков. Параметр запуска может находиться там, когда тесты выполняются в таком ответвлении:

<argLine>-Djava.net.useSystemProxies=true</argLine>

Объедините параметр с существующей конфигурацией проекта. Замена существующего argLine может отбросить агенты покрытия или другие необходимые настройки JVM. Если сборка не использует ответвление, вместо этого проверьте JVM, которая действительно выполняет тесты; argLine, согласно документации, действует только для ответвлённых запусков.

Свойство, не зависящее от запуска и передаваемое через механизм свойств тестового фреймворка, имеет другой жизненный цикл. Не предполагайте, что каждое свойство достигает VM достаточно рано только потому, что System.getProperty() во время теста возвращает нужную строку.

Для целенаправленного теста маршрутизации через прокси явно настроенный клиент тоже может уменьшить зависимость от конфигурации рабочего стола. Java 11+ HttpClient может использовать для этого локальный для клиента HTTP ProxySelector. Держите этот выбор видимым в замысле теста: проверка маршрута клиента и проверка обнаружения прокси операционной системой — это разные проверки.