L'applicazione rileva il proxy di sistema, ma un test JUnit no. Prima di modificare il codice di rilevamento, stabilisci quale JVM esegue ogni processo e quali argomenti ha ricevuto.

Il JDK documenta java.net.useSystemProxies come una proprietà controllata una sola volta all'avvio. Impostarla all'interno di un metodo di test può essere troppo tardi per cambiare quella decisione di avvio.

Un launcher di applicazioni IDE, un esecutore di test IDE, Maven stesso e un processo di test Surefire biforcato possono avere tutti argomenti VM diversi. Un'impostazione proxy in un launcher non è prova che un altro launcher l'abbia trasmessa.

Controlla la configurazione del processo biforcato

L'argLine di Surefire fornisce opzioni JVM da riga di comando per le esecuzioni biforcate. Un'opzione di avvio può appartenere lì quando i test vengono eseguiti in tale biforcazione:

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

Unisci l'opzione alla configurazione esistente del progetto. Sostituire un argLine esistente può scartare agenti di copertura o altre impostazioni JVM necessarie. Se la build non usa alcuna biforcazione, esamina invece la JVM che ospita davvero i test; argLine è documentato come efficace solo per le esecuzioni biforcate.

Una proprietà non sensibile all'avvio fornita tramite il meccanismo delle proprietà di un framework di test ha un ciclo di vita diverso. Non presumere che ogni proprietà raggiunga la VM abbastanza presto solo perché System.getProperty() restituisce la stringa desiderata durante il test.

Per un test mirato di instradamento proxy, un client configurato esplicitamente può anche ridurre la dipendenza dalla configurazione del desktop. Java 11+ HttpClient può usare a tale scopo un HTTP ProxySelector locale al client. Mantieni questa scelta visibile nell'intento del test: testare un percorso client e testare il rilevamento del proxy del sistema operativo sono controlli diversi.

Articoli correlati