რატომ გამოტოვებენ 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 დოკუმენტირებულია როგორც ეფექტური მხოლოდ განშტოებული გაშვებებისთვის.
ტესტის ჩარჩოს თვისებების მექანიზმით მიწოდებულ გაშვებაზე-მგრძნობიარე არარა თვისებას განსხვავებული სასიცოცხლო ციკლი აქვს. ნუ ჩათვლით, რომ ყოველი თვისება VM-ს საკმარისად ადრე აღწევს მხოლოდ იმიტომ, რომ System.getProperty() ტესტის დროს სასურველ სტრიქონს აბრუნებს.
ფოკუსირებული პროქსი-მარშრუტიზაციის ტესტისთვის, ცხადად კონფიგურირებულმა კლიენტმა ასევე შეიძლება შეამციროს დესკტოპის კონფიგურაციაზე დამოკიდებულება. Java 11+ HttpClient-ს შეუძლია ამ მიზნისთვის გამოიყენოს კლიენტის ლოკალური HTTP ProxySelector. შეინახეთ ეს არჩევანი ხილული ტესტის განზრახვაში: კლიენტის მარშრუტის ტესტირება და ოპერაციული სისტემის პროქსის აღმოჩენის ტესტირება სხვადასხვა შემოწმებაა.