Java ପରୀକ୍ଷଣ java.net.useSystemProxies କୁ କାହିଁକି ଛାଡ଼ିଦିଏ

ଆପଣଙ୍କ ଆପ୍ଲିକେସନ୍ ସିଷ୍ଟମ୍ ପ୍ରକ୍ସି ଚିହ୍ନଟ କରେ, କିନ୍ତୁ JUnit ପରୀକ୍ଷଣ କରେ ନାହିଁ। ଚିହ୍ନଟ କୋଡ୍ ବଦଳାଇବା ପୂର୍ବରୁ କେଉଁ JVM ପ୍ରତ୍ୟେକ ପ୍ରକ୍ରିୟା ଚଲାଏ ଏବଂ କେଉଁ ଆର୍ଗୁମେଣ୍ଟ ପାଇଲା ନିର୍ଣ୍ଣୟ କରନ୍ତୁ।

JDK java.net.useSystemProxies କୁ ଷ୍ଟାର୍ଟଅପ୍ ସମୟରେ ଥରେ ଯାଞ୍ଚ ହେଉଥିବା ପ୍ରପର୍ଟି ଭାବରେ ଲେଖେ। ଏହାକୁ ପରୀକ୍ଷଣ ପଦ୍ଧତି ଭିତରେ ସେଟ୍ କରିବା ସେହି ଷ୍ଟାର୍ଟଅପ୍ ନିଷ୍ପତ୍ତି ବଦଳାଇବା ପାଇଁ ବହୁତ ଡେରି ହୋଇପାରେ।

IDE ଆପ୍ଲିକେସନ୍ ଲଞ୍ଚର୍, IDE ପରୀକ୍ଷଣ ରନର୍, Maven ନିଜେ ଏବଂ ଫୋର୍କ କରାଯାଇଥିବା Surefire ପରୀକ୍ଷଣ ପ୍ରକ୍ରିୟାର VM ଆର୍ଗୁମେଣ୍ଟ ଅଲଗା ହୋଇପାରେ। ଗୋଟିଏ ଲଞ୍ଚରରେ ଥିବା ପ୍ରକ୍ସି ସେଟିଂ ଅନ୍ୟ ଲଞ୍ଚର୍ ଏହାକୁ ପଠାଇଛି ବୋଲି ପ୍ରମାଣ ନୁହେଁ।

ଫୋର୍କ କରାଯାଇଥିବା ପ୍ରକ୍ରିୟାର କନଫିଗରେସନ୍ ଯାଞ୍ଚ କରନ୍ତୁ

Surefire ର argLine ଫୋର୍କ କରାଯାଇଥିବା ନିଷ୍ପାଦନ ପାଇଁ କମାଣ୍ଡ-ଲାଇନ୍ JVM ବିକଳ୍ପ ଦିଏ। ପରୀକ୍ଷଣଗୁଡ଼ିକ ଏପରି ଫୋର୍କରେ ଚଲିଲେ ଷ୍ଟାର୍ଟଅପ୍ ବିକଳ୍ପ ସେଠାରେ ରହିପାରେ:

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

ବିକଳ୍ପକୁ ପ୍ରୋଜେକ୍ଟର ବିଦ୍ୟମାନ କନଫିଗରେସନରେ ମିଶାନ୍ତୁ। ବିଦ୍ୟମାନ argLine ବଦଳାଇବା ଦ୍ୱାରା କଭରେଜ୍ ଏଜେଣ୍ଟ କିମ୍ବା ଅନ୍ୟ ଆବଶ୍ୟକ JVM ସେଟିଂ ହରାଇପାରେ। ଯଦି ବିଲ୍ଡ କୌଣସି ଫୋର୍କ ବ୍ୟବହାର କରେ ନାହିଁ, ତେବେ ପରିବର୍ତ୍ତେ ପରୀକ୍ଷଣକୁ ପ୍ରକୃତରେ ହୋଷ୍ଟ କରୁଥିବା JVM ଯାଞ୍ଚ କରନ୍ତୁ; argLine କେବଳ ଫୋର୍କ କରାଯାଇଥିବା ନିଷ୍ପାଦନ ପାଇଁ ପ୍ରଭାବୀ ବୋଲି ଲେଖା ଅଛି।

ପରୀକ୍ଷଣ ଫ୍ରେମୱାର୍କର ପ୍ରପର୍ଟି ଯନ୍ତ୍ରକୌଶଳ ମାଧ୍ୟମରେ ଦିଆଯାଉଥିବା ଷ୍ଟାର୍ଟଅପ୍-ସମ୍ବେଦନଶୀଳ ନଥିବା ପ୍ରପର୍ଟିର ଜୀବନଚକ୍ର ଅଲଗା। ପରୀକ୍ଷଣ ସମୟରେ System.getProperty() ଇଚ୍ଛିତ ଷ୍ଟ୍ରିଙ୍ଗ ଫେରାଏ ବୋଲି ମାତ୍ର କାରଣରୁ ପ୍ରତ୍ୟେକ ପ୍ରପର୍ଟି VM ପାଖରେ ଯଥେଷ୍ଟ ଶୀଘ୍ର ପହଞ୍ଚେ ବୋଲି ଧରିନେବେ ନାହିଁ।

କେନ୍ଦ୍ରିତ ପ୍ରକ୍ସି-ରାଉଟିଂ ପରୀକ୍ଷଣ ପାଇଁ, ସ୍ପଷ୍ଟ ଭାବରେ କନଫିଗର କରାଯାଇଥିବା କ୍ଲାଏଣ୍ଟ ଡେସ୍କଟପ୍ କନଫିଗରେସନ ଉପରେ ନିର୍ଭରତା ମଧ୍ୟ କମାଇପାରେ। Java 11+ HttpClient ସେହି ଉଦ୍ଦେଶ୍ୟରେ କ୍ଲାଏଣ୍ଟ-ସ୍ଥାନୀୟ HTTP ProxySelector ବ୍ୟବହାର କରିପାରେ। ସେହି ଚୟନକୁ ପରୀକ୍ଷଣର ଉଦ୍ଦେଶ୍ୟରେ ଦୃଶ୍ୟମାନ ରଖନ୍ତୁ: କ୍ଲାଏଣ୍ଟ ମାର୍ଗ ପରୀକ୍ଷା କରିବା ଏବଂ ଅପରେଟିଂ ସିଷ୍ଟମର ପ୍ରକ୍ସି ଆବିଷ୍କାର ପରୀକ୍ଷା କରିବା ଅଲଗା ଯାଞ୍ଚ।