A túa aplicación detecta o proxy do sistema, pero unha proba de JUnit non. Antes de cambiar o código de detección, identifica que JVM executa cada proceso e que argumentos recibiu.

O JDK documenta java.net.useSystemProxies como unha propiedade que se comproba unha vez ao arrancar. Establecela dentro dun método de proba pode ser demasiado tarde para cambiar esa decisión de arranque.

Un lanzador de aplicacións do IDE, un executador de probas do IDE, o propio Maven e un proceso de probas Surefire bifurcado poden ter argumentos de VM diferentes. Unha configuración de proxy nun lanzador non é proba de que outro lanzador a pasase.

Comproba a configuración do proceso bifurcado

O argLine de Surefire fornece opcións de JVM de liña de ordes para execucións bifurcadas. Unha opción de arranque pode pertencer alí cando as probas se executan nesa bifurcación:

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

Fusiona a opción coa configuración existente do proxecto. Substituír un argLine existente pode descartar axentes de cobertura ou outros axustes de JVM necesarios. Se a compilación non usa ningunha bifurcación, inspecciona no seu lugar o JVM que realmente aloxa as probas; argLine está documentado como efectivo só para execucións bifurcadas.

Unha propiedade non sensible ao arranque fornecida mediante o mecanismo de propiedades dun framework de probas ten un ciclo de vida distinto. Non supoñas que toda propiedade chega ao VM con suficiente antelación só porque System.getProperty() devolve a cadea desexada durante a proba.

Para unha proba de encamiñamento de proxy centrada, un cliente configurado explicitamente tamén pode reducir a dependencia da configuración do escritorio. Java 11+ HttpClient pode usar para iso un HTTP ProxySelector local ao cliente. Mantén esa elección visible na intención da proba: probar unha ruta de cliente e probar a descuberta de proxy do sistema operativo son comprobacións distintas.

Artigos relacionados