Проксі рэпазітара Maven можа атрымліваць залежнасці, не наладжваючы HTTP-запыт, які робіць тэст. Наладзьце кліент у тэставай JVM.

Калі гэты кліент ўлічвае ўласцівасці HTTPS-проксі Java, змясціце гэты фрагмент унутры элемента configuration адпаведнага плагіна Surefire:

<systemPropertyVariables>
  <https.proxyHost>proxy.example</https.proxyHost>
  <https.proxyPort>8080</https.proxyPort>
</systemPropertyVariables>

Замяніце прыкладны адрас. Для тэстаў супраць публічных прызначэнняў, дзе дазволеныя публічныя пасярэднікі, спіс HTTP-проксі прапануе кандыдатаў у хасты і парты. Хост і порт — асобныя значэнні; выбірайце сямейства ўласцівасцей, якое адпавядае схеме прызначэння і бібліятэцы. А кліенту, створанаму з яўным аб'ектам проксі, патрэбны ўласны інтэрфейс наладкі.

Surefire звычайна запускае тэсты ў аддзеленай JVM. Не ўсе параметры запуску Maven даходзяць да гэтага працэсу. Выяўленне сістэмнага проксі, адчувальнае да запуску, патрабуе свайго параметра ў тэставай JVM падчас запуску. Нават калі тэсты дзеляць адзін працэс, бібліятэка можа ігнараваць стандартныя ўласцівасці проксі Java.

Трымайце ўнутраныя прамыя прызначэнні пад адпаведным правілам абыходу, аддзяляйце аўтэнтыфікацыю проксі ад аўтэнтыфікацыі прызначэння і не адключайце праверку сертыфікатаў. Адключэнне адгалінавання змяняе выкананне тэстаў; змена люстранага рэпазітара залежнасцей змяняе развязанне рэпазітара. Ні адно не дае адсутны маршрут тэставага кліента. Капіраванне ўсіх сістэмных уласцівасцей таксама можа раскрыць сакрэты.

Калі збой застаецца, запішыце тэставую JVM, HTTP-бібліятэку, мэту, выбраны проксі і першую няўдалую стадыю. Гэтыя назіранні паказваюць на наладку тэсту, пакідаючы працоўныя загрузкі рэпазітара зразумелымі.

Падобныя артыкулы