Java тесттери эмне үчүн java.net.useSystemProxies-ти байкабайт
Иштетүүгө сезимтал Java проксиин аныктоо параметрлерин тесттерди аткарган JVMге бергиле, колдонмого же build иштеткичине гана эмес.
Колдонмоңуз системалык проксини аныктайт, ал эми JUnit тести аныктабайт. Аныктоо кодун өзгөртүүдөн мурун кайсы JVM ар бир процессти аткарарын жана кандай аргументтерди алганын аныктаңыз.
JDK java.net.useSystemProxies параметрин иштетүү учурунда бир жолу текшерилүүчү касиет катары документтештирет. Аны тест ыкмасынын ичинде коюу ошол иштетүү чечимин өзгөртүү үчүн өтө кеч болушу мүмкүн.
IDE колдонмо иштеткичи, IDE тест жүргүзгүчү, Maven өзү жана тармакталган Surefire тест процесси ар кандай VM аргументтерине ээ болушу мүмкүн. Бир иштеткичтеги прокси жөндөөсү башка иштеткич аны бергенине далил эмес.
Тармакталган процесстин конфигурациясын текшериңиз
Surefire'дун argLine тармакталган аткаруулар үчүн буйрук сабынын JVM параметрлерин берет. Тесттер ушундай тармакта иштегенде иштетүү параметри ошол жерде болушу мүмкүн:
<argLine>-Djava.net.useSystemProxies=true</argLine>Параметрди долбоордун учурдагы конфигурациясына бириктириңиз. Учурдагы argLine'ды алмаштыруу камтуу агенттерин же башка керектүү JVM жөндөөлөрүн жоготушу мүмкүн. Эгер build эч кандай тармакты колдонбосо, анын ордуна тесттерди чындап хост кылган JVMди текшериңиз; argLine тармакталган аткаруулар үчүн гана натыйжалуу деп документтелген.
Тест фреймворкунун касиеттер механизми аркылуу берилген, иштетүүгө сезимтал эмес касиеттин жашоо цикли башка. System.getProperty() тест учурунда керектүү сапты кайтарат деген жалгыз себеп менен ар бир касиет VMге жетиштүү эрте жетет деп ойлобоңуз.
Багытталган прокси-маршруттоо тести үчүн ачык конфигурацияланган клиент жумуш үстөлүнүн конфигурациясына көз карандылыкты да азайта алат. Java 11+ HttpClient бул максатта клиентке жергиликтүү HTTP ProxySelector колдоно алат. Бул тандоону тесттин ниетинде көрүнүктүү кармаңыз: клиент маршрутун текшерүү жана операциялык системанын проксиин аныктоону текшерүү ар башка текшерүүлөр.