Waarom Java-toetse java.net.useSystemProxies miskyk
Gee beginstadium-sensitiewe Java-volmagopsporingsopsies aan die JVM wat die toetse uitvoer, nie net aan die toepassing of bouaansitter nie.
Jou toepassing bespeur die stelselvolmag, maar 'n JUnit-toets doen dit nie. Voordat jy die opsporingskode verander, bepaal watter JVM elke proses laat loop en watter argumente dit ontvang het.
Die JDK dokumenteer java.net.useSystemProxies as 'n eienskap wat een keer by die begin nagegaan word. Om dit binne 'n toetsmetode te stel, kan te laat wees om daardie beginbesluit te verander.
'n IDE-toepassingsaansitter, 'n IDE-toetsloper, Maven self en 'n gevurkte Surefire-toetsproses kan almal verskillende VM-argumente hê. 'n Volmaginstelling in een aansitter is nie bewys dat 'n ander aansitter dit oorgedra het nie.
Kontroleer die gekonfigureerde vurkproses
Surefire se argLine verskaf opdragreël-JVM-opsies vir gevurkte uitvoerings. 'n Beginopsie kan daar hoort wanneer die toetse in so 'n vurk loop:
<argLine>-Djava.net.useSystemProxies=true</argLine>Voeg die opsie by die projek se bestaande konfigurasie in. Om 'n bestaande argLine te vervang, kan dekkingsagente of ander vereiste JVM-instellings weggooi. As die bou geen vurk gebruik nie, ondersoek eerder die JVM wat die toetse werklik huisves; argLine is gedokumenteer as slegs effektief vir gevurkte uitvoerings.
'n Eienskap wat nie beginstadium-sensitief is nie en deur 'n toetsraamwerk se eienskapsmeganisme verskaf word, het 'n ander lewensiklus. Moet nie aanvaar dat elke eienskap die VM vroeg genoeg bereik bloot omdat System.getProperty() die gewenste string tydens die toets teruggee nie.
Vir 'n gerigte volmag-roeteringstoets kan 'n eksplisiet gekonfigureerde kliënt ook die afhanklikheid van lessenaarkonfigurasie verminder. Java 11+ HttpClient kan 'n kliënt-plaaslike HTTP ProxySelector vir daardie doel gebruik. Hou daardie keuse sigbaar in die toets se bedoeling: om 'n kliëntroete te toets en om die bedryfstelsel se volmagopsporing te toets, is verskillende kontroles.