നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സിസ്റ്റം പ്രോക്സി കണ്ടെത്തുന്നു, എന്നാൽ JUnit ടെസ്റ്റ് കണ്ടെത്തുന്നില്ല. കണ്ടെത്തൽ കോഡ് മാറ്റുന്നതിന് മുമ്പ്, ഏത് JVM ഓരോ പ്രോസസും പ്രവർത്തിപ്പിക്കുന്നു, ഏത് ആർഗ്യുമെന്റുകൾ ലഭിച്ചു എന്ന് കണ്ടെത്തുക.

JDK java.net.useSystemProxies സ്റ്റാർട്ടപ്പിൽ ഒരിക്കൽ പരിശോധിക്കുന്ന പ്രോപ്പർട്ടിയായി രേഖപ്പെടുത്തുന്നു. ഒരു ടെസ്റ്റ് മെത്തഡിനുള്ളിൽ ഇത് സെറ്റ് ചെയ്യുന്നത് ആ സ്റ്റാർട്ടപ്പ് തീരുമാനം മാറ്റാൻ വളരെ വൈകിയേക്കാം.

IDE ആപ്ലിക്കേഷൻ ലോഞ്ചർ, IDE ടെസ്റ്റ് റണ്ണർ, Maven തന്നെ, ഫോർക്ക് ചെയ്ത Surefire ടെസ്റ്റ് പ്രോസസ് എന്നിവയ്ക്ക് വ്യത്യസ്ത VM ആർഗ്യുമെന്റുകൾ ഉണ്ടാകാം. ഒരു ലോഞ്ചറിലെ പ്രോക്സി സെറ്റിംഗ് മറ്റൊരു ലോഞ്ചർ അത് കൈമാറി എന്നതിന് തെളിവല്ല.

ഫോർക്ക് ചെയ്ത പ്രോസസിന്റെ കോൺഫിഗറേഷൻ പരിശോധിക്കുക

argLine ഫോർക്ക് ചെയ്ത എക്സിക്യൂഷനുകൾക്ക് കമാൻഡ്-ലൈൻ JVM ഓപ്ഷനുകൾ നൽകുന്നു. ടെസ്റ്റുകൾ അത്തരം ഫോർക്കിൽ പ്രവർത്തിക്കുമ്പോൾ സ്റ്റാർട്ടപ്പ് ഓപ്ഷൻ അവിടെ ഉണ്ടാകാം:

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

ഓപ്ഷൻ പ്രോജക്റ്റിന്റെ നിലവിലുള്ള കോൺഫിഗറേഷനുമായി ലയിപ്പിക്കുക. നിലവിലുള്ള argLine മാറ്റുന്നത് കവറേജ് ഏജന്റുകളോ മറ്റ് ആവശ്യമായ JVM ക്രമീകരണങ്ങളോ നഷ്ടപ്പെടുത്താം. ബിൽഡ് ഫോർക്ക് ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, പകരം ടെസ്റ്റുകൾ യഥാർത്ഥത്തിൽ ഹോസ്റ്റ് ചെയ്യുന്ന JVM പരിശോധിക്കുക; argLine ഫോർക്ക് ചെയ്ത എക്സിക്യൂഷനുകൾക്ക് മാത്രം ഫലപ്രദമെന്ന് രേഖപ്പെടുത്തിയിരിക്കുന്നു.

ടെസ്റ്റ് ഫ്രെയിംവർക്കിന്റെ പ്രോപ്പർട്ടി സംവിധാനത്തിലൂടെ നൽകുന്ന സ്റ്റാർട്ടപ്പ്-സംവേദനക്ഷമമല്ലാത്ത പ്രോപ്പർട്ടിക്ക് വ്യത്യസ്ത ജീവിതചക്രമുണ്ട്. ടെസ്റ്റിനിടയിൽ System.getProperty() ആവശ്യമായ സ്ട്രിംഗ് നൽകുന്നു എന്നത് മാത്രം കാരണമാക്കി ഓരോ പ്രോപ്പർട്ടിയും VM-ലേക്ക് മതിയായ നേരത്തെ എത്തുന്നുവെന്ന് കരുതരുത്.

കേന്ദ്രീകൃത പ്രോക്സി-റൂട്ടിംഗ് ടെസ്റ്റിനായി, വ്യക്തമായി കോൺഫിഗർ ചെയ്ത ക്ലയന്റിന് ഡെസ്ക്ടോപ്പ് കോൺഫിഗറേഷനിലുള്ള ആശ്രിതത്വം കുറയ്ക്കാനും കഴിയും. Java 11+ HttpClient അതിനായി ക്ലയന്റ്-ലോക്കൽ HTTP ProxySelector ഉപയോഗിക്കാം. ആ തിരഞ്ഞെടുപ്പ് ടെസ്റ്റിന്റെ ഉദ്ദേശ്യത്തിൽ ദൃശ്യമായി നിർത്തുക: ഒരു ക്ലയന്റ് റൂട്ട് പരിശോധിക്കുന്നതും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ പ്രോക്സി കണ്ടെത്തൽ പരിശോധിക്കുന്നതും വ്യത്യസ്ത പരിശോധനകളാണ്.

അനുബന്ധ ലേഖനങ്ങൾ