Чому тести Java не бачать java.net.useSystemProxies
Передавайте залежні від запуску параметри виявлення проксі Java у JVM, яка запускає тести, а не лише в застосунок або лаунчер збірки.
Ваш застосунок визначає системний проксі, а тест 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. Тримайте цей вибір видимим у намірі тесту: перевірка маршруту клієнта й перевірка виявлення проксі операційної системи — це різні перевірки.