Тэставанне мікрасэрвісаў - кіраўніцтва для пачаткоўцаў

Тэставанне мікрасэрвісаў набывае ўсё большае значэнне, бо многія новыя дадаткі ствараюцца з выкарыстаннем архітэктуры мікрасэрвісаў.

Перш чым мы зможам убачыць, як праверыць мікрасэрвісы, спачатку трэба зразумець, што яны сабой уяўляюць.



Што такое мікрасэрвісы?

Мікрасэрвіс вызначаецца як архітэктурны стыль, падыход да распрацоўкі адзінага прыкладання як набору паслуг. Кожная паслуга вызначаецца сваімі характарыстыкамі, некаторыя з якіх:


  • Запуск у яго працэсе.
  • Сувязь з лёгкім механізмам часта з API рэсурсаў HTTP.
  • Незалежнае разгортванне на цалкам аўтаматызаваным абсталяванні.
  • Выкарыстанне розных моў праграмавання / тэхналогій / БД.
  • Выкарыстоўвае розныя тэхналогіі захоўвання дадзеных.

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

Характарыстыкі мікрасэрвісаў:


  • Арганізаваны вакол дзелавога патэнцыялу,
  • Аўтаматызаванае разгортванне,
  • Інтэлект у канчатковых кропках, а не ў службовай шыне,
  • Дэцэнтралізаваны кантроль над мовамі і дадзенымі.


Чым адрозніваюцца мікрасэрвісы ад SOA

  • Архітэктура, арыентаваная на паслугі (SOA): архітэктурны ўзор пры распрацоўцы камп'ютэрнага праграмнага забеспячэння, пры якім кампаненты прыкладання прадастаўляюць паслугі іншым кампанентам праз пратакол сувязі, звычайна па сетцы.
  • Мікрасэрвісы : Стыль архітэктурнай праграмы, у якім складаныя прыкладання складаюцца з невялікіх незалежных працэсаў, якія ўзаемадзейнічаюць паміж сабой з выкарыстаннем моўна-агностычных API

Прыклад:



Калі Uber быў пабудаваны з SOA, іх паслугі могуць быць:

  • GetPaymentsAndDriverInformationAndMappingDataAPI
  • AuthenticateUsersAndDriversAPI

Калі Uber быў пабудаваны з мікрасэрвісамі, іх API можа быць больш падобным на:

  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService

Больш API, меншы набор абавязкаў.




Як праверыць мікрасэрвісы

Адзінкавыя тэсты

Юнітарныя тэсты выкарыстоўваюць невялікія фрагменты праграмнага забеспячэння, такія як функцыі ў дадатку, каб вызначыць, ці вырабляюць яны патрэбны вынік з улікам набору вядомых уваходаў.

Варта адзначыць, што адзінкавае тэсціраванне не дае гарантый паводзін сістэмы. Нам патрэбны іншыя віды тэставання на мікрасэрвісы.

Кампанентныя выпрабаванні

Пасля таго, як мы правялі модульнае тэсціраванне ўсіх функцый у мікраслужбе, нам трэба праверыць саму мікраслужбу ў ізаляцыі.

Як правіла, прыкладанне будзе складацца з шэрагу мікрасэрвісаў, таму для таго, каб праверыць ізалявана, нам трэба здзекавацца над іншымі мікрасэрвісамі.


Кампанентныя тэсты таксама будуць правяраць узаемадзеянне мікраслужбы з такімі залежнасцямі, як база дадзеных, усё як адзінае цэлае.

Інтэграцыйныя тэсты

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

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

Кантрактныя выпрабаванні

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


Гэты тып тэставання павінен разглядаць кожную службу як чорную скрыню, і ўсе службы павінны выклікаць незалежна адзін ад аднаго, а іх адказы павінны быць правераны.

«Кантракт» - гэта спосаб звароту да паслугі (дзе для пэўных уваходаў чакаецца пэўны вынік альбо вынік) пры тэставанні спажывецкага кантракту. Кожны спажывец павінен атрымліваць аднолькавыя вынікі ад паслуг з цягам часу, нават калі паслуга змяняецца. Павінна быць гнуткасць, каб дадаць больш функцыянальных магчымасцей у залежнасці ад Адказаў пазней. Аднак гэтыя дапаўненні не павінны парушаць функцыянальнасць службы.

Скразныя выпрабаванні

Роля скразных тэстаў заключаецца ў тым, каб пераканацца, што ўсё звязана паміж сабой, і няма ніякіх рознагалоссяў паміж мікраслужбамі.

Скразныя выпрабаванні пераконваюць, што сістэма адпавядае знешнім патрабаванням і дасягае сваіх мэтаў, тэстуючы ўсю сістэму ад канца да канца.


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



Прыклад тэставання мікрасэрвісаў

Возьмем мікрасэрвіс ДА гэта залежыць ад двух іншых паслуг Б & З . Вам трэба стварыць ізаляванае асяроддзе, дзе стан ДА , Б і З дакладна вызначаны і можа быць неаднаразова наладжаны.

Напрыклад, стан / захоўванне Б і З павінны быць папярэдне ініцыялізаваны. Пасля гэтага вы проста запусціце набор тэстаў, якія тэстуюць API мікрасэрвіса ДА з выкарыстаннем звычайнага набору тэставых інструментаў REST / WebService, напрыклад Мыла альбо Чакрам альбо простая альтэрнатыва xUnit для вашай мовы праграмавання.

Здзекуйцеся над любымі аднагодкамі, якія API залежыць ад выкарыстання restito. Іншыя альтэрнатывы - драйвер адпачынку, WireMock і Mochito.

Відавочнай праблемай з'яўляецца здзек / падробка старонніх API пры правядзенні інтэграцыйнага тэсціравання мікраслужбаў. Вы можаце выкарыстоўваць любы з вышэйзгаданых інструментаў, згаданых вышэй, проста разгледзьце здзекі як частку нашага тэставага прыстасавання і пераканайцеся, што вы ў курсе новых выпускаў API.