ເປັນຫຍັງການທົດສອບ Java ຈຶ່ງບໍ່ເຫັນ java.net.useSystemProxies

ແອັບຯຂອງທ່ານກວດພົບ proxy ຂອງລະບົບ, ແຕ່ການທົດສອບ JUnit ບໍ່ພົບ. ກ່ອນຈະປ່ຽນໂຄດກວດພົບ, ກຳນົດວ່າ JVM ໃດຮັນແຕ່ລະຂະບວນການ ແລະ ໄດ້ຮັບ argument ໃດ.

JDK ບັນທຶກ java.net.useSystemProxies ເປັນຄຸນສົມບັດທີ່ກວດພຽງເທື່ອດຽວຕອນເລີ່ມຕົ້ນ. ການຕັ້ງຄ່າມັນພາຍໃນເມທັດທົດສອບອາດຊ້າເກີນໄປທີ່ຈະປ່ຽນການຕັດສິນໃຈເລີ່ມຕົ້ນນັ້ນ.

ຕົວເລີ່ມແອັບ IDE, ຕົວຮັນການທົດສອບ IDE, Maven ເອງ ແລະ ຂະບວນການທົດສອບ Surefire ທີ່ແຍກສາຂາ ອາດມີ argument VM ຕ່າງກັນ. ການຕັ້ງ proxy ໃນຕົວເລີ່ມໜຶ່ງບໍ່ແມ່ນຫຼັກຖານວ່າຕົວເລີ່ມອື່ນສົ່ງມັນຕໍ່.

ກວດເບິ່ງການຕັ້ງຄ່າຂະບວນການທີ່ແຍກສາຂາ

argLine ຂອງ Surefire ໃຫ້ຕົວເລືອກ JVM ຕາມແຖວຄຳສັ່ງສຳລັບການຮັນທີ່ແຍກສາຂາ. ຕົວເລືອກການເລີ່ມຕົ້ນອາດຢູ່ທີ່ນັ້ນເມື່ອການທົດສອບຮັນໃນສາຂາແບບນັ້ນ:

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

ລວມຕົວເລືອກເຂົ້າກັບການຕັ້ງຄ່າທີ່ມີຢູ່ຂອງໂຄງການ. ການປ່ຽນ argLine ທີ່ມີຢູ່ອາດຖິ້ມ coverage agent ຫຼື ການຕັ້ງຄ່າ JVM ອື່ນທີ່ຈຳເປັນ. ຖ້າ build ບໍ່ໃຊ້ສາຂາໃດໆ, ໃຫ້ກວດ JVM ທີ່ໂຮສການທົດສອບຕົວຈິງແທນ; argLine ຖືກບັນທຶກວ່າມີຜົນສະເພາະການຮັນທີ່ແຍກສາຂາເທົ່ານັ້ນ.

ຄຸນສົມບັດທີ່ບໍ່ອ່ອນໄຫວຕໍ່ການເລີ່ມຕົ້ນ ທີ່ສະໜອງຜ່ານກົນໄກຄຸນສົມບັດຂອງ framework ທົດສອບ ມີວົງຈອນຊີວິດຕ່າງກັນ. ຢ່າສົມມຸດວ່າທຸກຄຸນສົມບັດໄປຮອດ VM ໄວພຽງພໍ ພຽງເພາະ System.getProperty() ສົ່ງຄືນສະຕຣິງທີ່ຕ້ອງການລະຫວ່າງການທົດສອບ.

ສຳລັບການທົດສອບການເສັ້ນທາງ proxy ແບບເຈາະຈົງ, ລູກຄ້າທີ່ຕັ້ງຄ່າຢ່າງຊັດເຈນຍັງສາມາດຫຼຸດການອີງໃສ່ການຕັ້ງຄ່າເດສກທັອບ. Java 11+ HttpClient ສາມາດໃຊ້ HTTP ProxySelector ພາຍໃນລູກຄ້າ ເພື່ອຈຸດປະສົງນັ້ນ. ເກັບທາງເລືອກນັ້ນໃຫ້ເຫັນໃນເຈດຕະນາຂອງການທົດສອບ: ການທົດສອບເສັ້ນທາງລູກຄ້າ ແລະ ການທົດສອບການຄົ້ນຫາ proxy ຂອງລະບົບປະຕິບັດການ ແມ່ນການກວດສອບທີ່ແຕກຕ່າງກັນ.