Защо тестовете на 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. Дръжте този избор видим в намерението на теста: тестването на клиентски маршрут и тестването на откриването на прокси от операционната система са различни проверки.