Kodėl Java testai nepastebi java.net.useSystemProxies
Perduokite paleidimo metu jautrias Java proxy aptikimo parinktis testus vykdančiai JVM, o ne tik programai ar build paleidikliui.
Jūsų programa aptinka sistemos proxy, o JUnit testas – ne. Prieš keisdami aptikimo kodą, nustatykite, kuri JVM vykdo kiekvieną procesą ir kokius argumentus ji gavo.
JDK dokumentuoja java.net.useSystemProxies kaip ypatybę, kuri tikrinama vieną kartą paleidžiant. Jos nustatymas testo metodo viduje gali būti per vėlu pakeisti tą paleidimo sprendimą.
IDE programos paleidiklis, IDE testų vykdyklė, pats Maven ir atšakytasis Surefire testo procesas gali turėti skirtingus VM argumentus. Proxy nustatymas viename paleidiklyje nėra įrodymas, kad kitas paleidiklis jį perdavė.
Patikrinkite atšakytojo proceso konfigūraciją
Surefire argLine pateikia komandinės eilutės JVM parinktis atšakytiems vykdymams. Paleidimo parinktis gali priklausyti ten, kai testai vykdomi tokiame atšakojime:
<argLine>-Djava.net.useSystemProxies=true</argLine>Sujunkite parinktį su esama projekto konfigūracija. Pakeitus esamą argLine galima prarasti padengimo agentus ar kitus reikiamus JVM nustatymus. Jei build nenaudoja jokio atšakojimo, patikrinkite JVM, kuris iš tikrųjų talpina testus; argLine dokumentuojama kaip veikianti tik atšakytiems vykdymams.
Ypatybė, kuri nėra jautri paleidimui ir pateikiama per testų karkaso ypatybių mechanizmą, turi kitą gyvavimo ciklą. Nemanau, kad kiekviena ypatybė VM pasiekia pakankamai anksti vien todėl, kad System.getProperty() testo metu grąžina norimą eilutę.
Tiksliniam proxy maršrutizavimo testui aiškiai sukonfigūruotas klientas taip pat gali sumažinti priklausomybę nuo darbalaukio konfigūracijos. Java 11+ HttpClient tam gali naudoti kliento lokalų HTTP ProxySelector. Laikykite šį pasirinkimą matomą testo ketinime: kliento maršruto testavimas ir operacinės sistemos proxy aptikimo testavimas yra skirtingi patikrinimai.