Sua aplicação detecta o proxy do sistema, mas um teste JUnit não. Antes de alterar o código de detecção, identifique qual JVM executa cada processo e quais argumentos ela recebeu.

O JDK documenta java.net.useSystemProxies como uma propriedade verificada uma vez na inicialização. Defini-la dentro de um método de teste pode ser tarde demais para alterar essa decisão de inicialização.

Um lançador de aplicação da IDE, um executor de testes da IDE, o próprio Maven e um processo de testes Surefire bifurcado podem ter argumentos de VM diferentes. Uma configuração de proxy em um lançador não é prova de que outro lançador a repassou.

Verifique a configuração do processo bifurcado

O argLine do Surefire fornece opções JVM de linha de comando para execuções bifurcadas. Uma opção de inicialização pode pertencer ali quando os testes são executados nessa bifurcação:

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

Mescle a opção à configuração existente do projeto. Substituir um argLine existente pode descartar agentes de cobertura ou outras configurações de JVM necessárias. Se o build não usar nenhuma bifurcação, inspecione em vez disso a JVM que realmente hospeda os testes; argLine está documentado como eficaz apenas para execuções bifurcadas.

Uma propriedade não sensível à inicialização fornecida pelo mecanismo de propriedades de uma estrutura de testes tem um ciclo de vida diferente. Não presuma que toda propriedade chega à VM cedo o bastante só porque System.getProperty() retorna a string desejada durante o teste.

Para um teste focado de roteamento por proxy, um cliente configurado explicitamente também pode reduzir a dependência da configuração da área de trabalho. O Java 11+ HttpClient pode usar para isso um HTTP ProxySelector local ao cliente. Mantenha essa escolha visível na intenção do teste: testar uma rota de cliente e testar a descoberta de proxy do sistema operacional são verificações diferentes.

Artigos relacionados