Ձեր հավելվածը հայտնաբերում է համակարգի վստահված սերվերը, իսկ 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-ը փաստագրված է որպես արդյունավետ միայն ճյուղավորված կատարումների համար։

Թեստային շրջանակի հատկությունների մեխանիզմով տրված ոչ մեկնարկային-զգայուն հատկությունն ունի այլ կենսացիկլ։ Մի ենթադրեք, որ յուրաքանչյուր հատկություն հասնում է VM-ին բավական վաղ միայն այն պատճառով, որ System.getProperty()-ը թեստի ընթացքում վերադարձնում է ցանկալի տողը։

Կենտրոնացված վստահված սերվերի երթուղավորման թեստի համար բացահայտ կարգավորված հաճախորդը նույնպես կարող է նվազեցնել աշխատասեղանի կարգավորումից կախվածությունը։ Java 11+ HttpClient-ը կարող է այդ նպատակով օգտագործել հաճախորդին լոկալ HTTP ProxySelector։ Պահեք այդ ընտրությունը տեսանելի թեստի մտադրության մեջ. հաճախորդի երթուղին ստուգելը և օպերացիոն համակարգի վստահված սերվերի հայտնաբերումը ստուգելը տարբեր ստուգումներ են։

Առնչվող հոդվածներ