Wêrom Java-tests java.net.useSystemProxies misse
Jou startgefoelige Java-proxy-ûntdekkingsopsjes troch oan 'e JVM dy't de tests rint, net allinnich oan 'e applikaasje of de build-starter.
Jo applikaasje detektearret de systeemproxy, mar in JUnit-test docht dat net. Foardat jo de deteksjekoade feroarje, bepale hokker JVM elk proses rint en hokker arguminten it krigen hat.
De JDK dokumintearret java.net.useSystemProxies as in eigenskip dy't ien kear by it starten kontrolearre wurdt. It yn in testmetoade ynstelle kin te let wêze om dy startbeslissing te feroarjen.
In IDE-applikaasjestarter, in IDE-testrunner, Maven sels en in foarke Surefire-testproses kinne allegear ferskate VM-arguminten hawwe. In proxy-ynstelling yn ien starter is gjin bewiis dat in oare starter dy trochjûn hat.
Kontrolearje de konfiguraasje fan it foarke proses
Surefire's argLine leveret JVM-opsjes foar de kommandorigel foar foarke útfieringen. In startopsje kin dêr thúshearre as de tests yn sa'n foarke rinne:
<argLine>-Djava.net.useSystemProxies=true</argLine>Foegje de opsje gear mei de besteande konfiguraasje fan it projekt. It ferfangen fan in besteande argLine kin dekkingsaginten of oare fereaske JVM-ynstellingen weilitte. As de build gjin foarke brûkt, ûndersykje dan ynstee de JVM dy't de tests feitlik hostet; argLine is dokumintearre as allinnich effektyf foar foarke útfieringen.
In net-startgefoelige eigenskip levere fia it eigenskippmeganisme fan in testframework hat in oare libbenssyklus. Nim net oan dat elke eigenskip de VM betiid genôch berikt, allinnich om't System.getProperty() by de test de winske tekenrige weromjout.
Foar in rjochte proxy-routingtest kin in eksplisyt konfigurearre klant ek de ôfhinklikens fan buroblêdkonfiguraasje ferminderje. Java 11+ HttpClient kin dêrfoar in klant-lokale HTTP ProxySelector brûke. Hâld dy kar sichtber yn 'e bedoeling fan 'e test: in klantrûte testen en it ûntdekken fan operaasjesysteemproxy testen binne ferskate kontrôles.