Kial Java-testoj maltrafas java.net.useSystemProxies
Transdonu startosentemajn agordojn de Java-proksea malkovro al la JVM, kiu rulas la testojn, ne nur al la aplikaĵo aŭ al la konstrua lanĉilo.
Via aplikaĵo detektas la sisteman prokseon, sed JUnit-testo ne. Antaŭ ol ŝanĝi la detektan kodon, identigu, kiu JVM rulas ĉiun procezon kaj kiujn argumentojn ĝi ricevis.
La JDK dokumentas java.net.useSystemProxies kiel econ kontrolatan unufoje ĉe starto. Agordi ĝin ene de testmetodo povas esti tro malfrue por ŝanĝi tiun startan decidon.
IDE-aplikaĵa lanĉilo, IDE-testa rulilo, Maven mem kaj forkiĝinta Surefire-testa procezo povas ĉiuj havi malsamajn VM-argumentojn. Proksea agordo en unu lanĉilo ne pruvas, ke alia lanĉilo transdonis ĝin.
Kontrolu la agordon de la forkiĝinta procezo
Surefire-a argLine provizas komandliniajn JVM-agordojn por forkiĝintaj plenumoj. Starta agordo povas aparteni tien, kiam la testoj rulas en tia forko:
<argLine>-Djava.net.useSystemProxies=true</argLine>Kunfandu la agordon en la ekzistantan agordon de la projekto. Anstataŭigi ekzistantan argLine povas forĵeti kovrilajn agentojn aŭ aliajn bezonatajn JVM-agordojn. Se la konstruo uzas neniun forkon, anstataŭe inspektu la JVM, kiu efektive gastigas la testojn; argLine estas dokumentita kiel efika nur por forkiĝintaj plenumoj.
Eco ne startosentema, provizita per la eco-mekanismo de testa kadro, havas alian vivociklon. Ne supozu, ke ĉiu eco atingas la VM sufiĉe frue nur ĉar System.getProperty() redonas la deziratan ĉenon dum la testo.
Por celita proksea enkursiga testo, eksplicite agordita kliento ankaŭ povas malpliigi dependecon de labortabla agordo. Java 11+ HttpClient povas uzi por tiu celo klient-lokan HTTP ProxySelector. Konservu tiun elekton videbla en la intenco de la testo: testi klientan itineron kaj testi malkovron de la operaciuma prokseo estas malsamaj kontroloj.