Зошто 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 локален за клиентот. Чувајте го тој избор видлив во намерата на тестот: тестирањето на клиентска рута и тестирањето на откривањето прокси на оперативниот систем се различни проверки.