Java testleri java.net.useSystemProxies'i neden kaçırır

Uygulamanız sistem proxy'sini algılar, ancak bir JUnit testi algılamaz. Algılama kodunu değiştirmeden önce hangi JVM'nin her süreci çalıştırdığını ve hangi bağımsız değişkenleri aldığını belirleyin.

JDK, java.net.useSystemProxies öğesini başlangıçta bir kez denetlenen bir özellik olarak belgeler. Bunu bir test yöntemi içinde ayarlamak, o başlangıç kararını değiştirmek için çok geç olabilir.

Bir IDE uygulama başlatıcısı, bir IDE test çalıştırıcısı, Maven'in kendisi ve çatallanmış bir Surefire test süreci farklı VM bağımsız değişkenlerine sahip olabilir. Bir başlatıcıdaki proxy ayarı, başka bir başlatıcının bunu ilettiğinin kanıtı değildir.

Çatallanmış süreç yapılandırmasını denetleyin

Surefire'in argLine öğesi çatallanmış yürütmeler için komut satırı JVM seçenekleri sağlar. Testler böyle bir çatalda çalıştığında başlangıç seçeneği oraya ait olabilir:

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

Seçeneği projenin mevcut yapılandırmasıyla birleştirin. Var olan bir argLine'ı değiştirmek kapsam ajanlarını veya diğer gerekli JVM ayarlarını atabilir. Derleme herhangi bir çatal kullanmıyorsa, bunun yerine testleri gerçekten barındıran JVM'i inceleyin; argLine yalnızca çatallanmış yürütmeler için etkili olarak belgelenmiştir.

Bir test çerçevesinin özellik mekanizmasıyla sağlanan ve başlangıca duyarlı olmayan bir özelliğin yaşam döngüsü farklıdır. Sırf System.getProperty() test sırasında istenen dizeyi döndürdüğü için her özelliğin VM'e yeterince erken ulaştığını varsaymayın.

Odaklanmış bir proxy yönlendirme testi için açıkça yapılandırılmış bir istemci, masaüstü yapılandırmasına bağımlılığı da azaltabilir. Java 11+ HttpClient bunun için istemciye yerel bir HTTP ProxySelector kullanabilir. Bu seçimi testin amacında görünür tutun: bir istemci yolunu test etmek ile işletim sisteminin proxy keşfini test etmek farklı denetimlerdir.