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 ను ఉపయోగించగలదు. ఆ ఎంపికను పరీక్ష ఉద్దేశంలో కనిపించేలా ఉంచండి: క్లయింట్ మార్గాన్ని పరీక్షించడం మరియు ఆపరేటింగ్ సిస్టమ్ ప్రాక్సీ గుర్తింపును పరీక్షించడం వేర్వేరు తనిఖీలు.