למה בדיקות Java מפספסות את java.net.useSystemProxies
העבר את אפשרויות גילוי הפרוקסי של Java הרגישות לאתחול אל ה-JVM שמריץ את הבדיקות, ולא רק אל היישום או אל מפעיל הבנייה.
היישום שלך מזהה את פרוקסי המערכת, אבל בדיקת JUnit לא. לפני שינוי קוד הזיהוי, קבע איזה JVM מריץ כל תהליך ואילו ארגומנטים הוא קיבל.
ה-JDK מתעד את java.net.useSystemProxies כמאפיין שנבדק פעם אחת בעת האתחול. הגדרתו בתוך שיטת בדיקה עשויה להיות מאוחרת מדי כדי לשנות את החלטת האתחול הזו.
מפעיל יישום של IDE, מריץ בדיקות של IDE, Maven עצמו ותהליך בדיקות Surefire מסועף יכולים כולם לקבל ארגומנטים שונים של VM. הגדרת פרוקסי במפעיל אחד אינה הוכחה שמפעיל אחר העביר אותה.
בדוק את תצורת התהליך המסועף
argLine של Surefire מספק אפשרויות JVM של שורת הפקודה עבור הרצות מסועפות. אפשרות אתחול יכולה להשתייך לשם כאשר הבדיקות רצות בענף כזה:
<argLine>-Djava.net.useSystemProxies=true</argLine>מזג את האפשרות בתצורה הקיימת של הפרויקט. החלפת argLine קיים עלולה להשליך סוכני כיסוי או הגדרות JVM נדרשות אחרות. אם הבנייה אינה משתמשת בענף, בדוק במקום זאת את ה-JVM שמארח בפועל את הבדיקות; argLine מתועד כיעיל רק עבור הרצות מסועפות.
למאפיין שאינו רגיש לאתחול ושמסופק דרך מנגנון המאפיינים של מסגרת בדיקות יש מחזור חיים שונה. אל תניח שכל מאפיין מגיע ל-VM מוקדם מספיק רק משום ש-System.getProperty() מחזיר את המחרוזת הרצויה במהלך הבדיקה.
עבור בדיקת ניתוב פרוקסי ממוקדת, לקוח שהוגדר במפורש יכול גם להפחית את התלות בתצורת שולחן העבודה. Java 11+ HttpClient יכול להשתמש לשם כך ב-HTTP ProxySelector מקומי ללקוח. שמור את הבחירה הזו גלויה בכוונת הבדיקה: בדיקת מסלול לקוח ובדיקת גילוי הפרוקסי של מערכת ההפעלה הן בדיקות שונות.