Miksi Java-testit eivät havaitse java.net.useSystemProxies-asetusta

Sovelluksesi havaitsee järjestelmän välityspalvelimen, mutta JUnit-testi ei. Ennen tunnistuskoodin muuttamista selvitä, mikä JVM ajaa kunkin prosessin ja mitkä argumentit se sai.

JDK dokumentoi java.net.useSystemProxies-asetuksen ominaisuudeksi, joka tarkistetaan kerran käynnistyksen yhteydessä. Sen asettaminen testimetodin sisällä voi olla liian myöhäistä kyseisen käynnistyspäätöksen muuttamiseen.

IDE-sovelluskäynnistäjällä, IDE-testiajurilla, Mavenilla itsellään ja haarautetulla Surefire-testiprosessilla voi kaikilla olla eri VM-argumentit. Yhdessä käynnistäjässä tehty välityspalvelinasetus ei todista, että toinen käynnistäjä välitti sen.

Tarkista haarautetun prosessin kokoonpano

Surefiren argLine tarjoaa komentorivin JVM-asetukset haarautetuille suorituksille. Käynnistysasetus voi kuulua sinne, kun testit ajetaan sellaisessa haarassa:

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

Yhdistä asetus projektin olemassa olevaan kokoonpanoon. Olemassa olevan argLine-asetuksen korvaaminen voi pudottaa kattavuusagentit tai muita vaadittuja JVM-asetuksia. Jos build ei käytä haaraa, tutki sen sijaan JVM, joka todella isännöi testit; argLine on dokumentoitu tehokkaaksi vain haarautetuille suorituksille.

Testikehyksen ominaisuusmekanismin kautta välitetyn ei-käynnistysherkän ominaisuuden elinkaari on erilainen. Älä oleta, että jokainen ominaisuus saavuttaa VM:n riittävän aikaisin vain siksi, että System.getProperty() palauttaa halutun merkkijonon testin aikana.

Kohdennettuun välityspalvelinreititystestiin voi myös eksplisiittisesti määritetty asiakasohjelma vähentää riippuvuutta työpöydän kokoonpanosta. Java 11+ HttpClient voi käyttää siihen asiakaskohtaista HTTP ProxySelector-valitsinta. Pidä tämä valinta näkyvissä testin tarkoituksessa: asiakasreitin testaaminen ja käyttöjärjestelmän välityspalvelimen tunnistuksen testaaminen ovat eri tarkistuksia.