Pourquoi les tests Java manquent java.net.useSystemProxies

Votre application détecte le proxy système, mais un test JUnit ne le fait pas. Avant de modifier le code de détection, identifiez quelle JVM exécute chaque processus et quels arguments elle a reçus.

Le JDK documente java.net.useSystemProxies comme une propriété vérifiée une seule fois au démarrage. La définir à l'intérieur d'une méthode de test peut être trop tard pour modifier cette décision de démarrage.

Un lanceur d'application IDE, un exécuteur de tests IDE, Maven lui-même et un processus de test Surefire forké peuvent tous avoir des arguments de VM différents. Un réglage de proxy dans un lanceur ne prouve pas qu'un autre lanceur l'a transmis.

Vérifiez la configuration du processus forké

L'argLine de Surefire fournit des options JVM de ligne de commande pour les exécutions forkées. Une option de démarrage peut y avoir sa place lorsque les tests s'exécutent dans un tel fork :

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

Fusionnez l'option avec la configuration existante du projet. Remplacer un argLine existant peut écarter des agents de couverture ou d'autres réglages JVM requis. Si le build n'utilise aucun fork, inspectez plutôt la JVM qui héberge réellement les tests ; argLine est documenté comme effectif uniquement pour les exécutions forkées.

Une propriété non sensible au démarrage fournie via le mécanisme de propriétés d'un framework de test a un cycle de vie différent. Ne supposez pas que chaque propriété atteint la VM assez tôt simplement parce que System.getProperty() renvoie la chaîne souhaitée pendant le test.

Pour un test ciblé de routage par proxy, un client explicitement configuré peut aussi réduire la dépendance à la configuration du bureau. Java 11+ HttpClient peut utiliser pour cela un HTTP ProxySelector local au client. Gardez ce choix visible dans l'intention du test : tester une route client et tester la découverte du proxy par le système d'exploitation sont des vérifications différentes.