Need on ekspertide sõnul kõige tõhusamad mikroteenuste testimise strateegiad

Mikroteenuste testimine on keeruline. Täpsemalt öeldes on otsast-lõpuni testimine keeruline ja seda me käsitleme selles artiklis üksikasjalikumalt.

Aga kõigepealt kiire lugu.

Sain teada, kui raske võib olla mikroteenuste testimine, kui ma esimest korda seitsme eraldi mikroteenusega tehnikapakku sukeldusin. Mõlemal oli oma koodibaas, sõltuvushaldus, funktsiooniharud ja andmebaasiskeem - millel oli juhuslikult ka ainulaadne migratsioonide komplekt.

Räägi ärevusest.

Lähenemisviis oli see, et jooksime kõike kohapeal. Nii et see tähendas, et igal ajahetkel, kui tahan läbi viia lõpptestid, peaksin läbima seitsme mikroteenuse jaoks järgmised viis sammu:

  1. Veenduge, et olin õigel koodiharul (kas põhi- või feature_xyz)
  2. Tõmmake selle haru uusim kood alla
  3. Veenduge, et kõik sõltuvused oleksid ajakohased
  4. Käivitage kõik uued andmebaaside migreerimised
  5. Käivitage teenus

See oli testide läbiviimise võimaldamiseks vaid põhinõue. Sageli unustasin teenuse jaoks ühe neist toimingutest teha ja kulutasin 10–15 minutit probleemi silumiseks. Kui mul olid lõpuks kõik teenused õnnelikud ja käimas, võisin hakata testikomplekti käivitama. See kogemus pani mind kindlasti ühe suure monoliidi testimise päevi igatsema.

Nii et jah, avastasin, et mikroteenuste testimine otsast otsani on keeruline - ja see muutub iga kasutatava uue teenusega eksponentsiaalselt raskemaks. Kuid ärge kartke, sest mikroteenuste testimise hõlbustamiseks on olemas viise. Olen rääkinud mitme CTO-ga, kuidas nad selle keerulise probleemi lahendamiseks ise oma loomingulised viisid välja mõtlesid.

Levinud mikroteenuste testimise meetodid

Üksuse testimine

Mikroteenus võib olla definitsiooni järgi väiksem, kuid ühikutestimise abil saate minna veelgi täpsemaks. Ühikutest keskendub testitava tarkvara väikseimale osale, et teha kindlaks, kas see komponent töötab nii, nagu peaks. Tunnustatud tarkvarainsener, autor ja rahvusvaheline esineja Martin Fowler jagab seadme testimise kahte kategooriasse:

  1. Seltskondlik ühikutestimine: see ühikutestimise meetod testib moodulite käitumist, jälgides nende oleku muutusi.
  2. Üksiküksuse testimine: see meetod keskendub objekti ja selle sõltuvuste vastastikmõjudele ja koostööle, mis asendatakse testdublettidega.

Ehkki need üksuste testimise strateegiad on erinevad, väidab Fowler, et nad ei konkureeri - neid saab kasutada erinevate testimisprobleemide lahendamiseks koos.

Arutelu ajal Pantheoni CTO David Straussiga ütles David mulle, et "võimalus on see, et mikroteenused on väga lihtsad, et tegelikult seadmeid testida."

Integreerimise testimine

Integreerimistestide abil teete seda, mis kõlab nagu teete: testige komponentide vahelisi kommunikatsiooniteid ja interaktsioone probleemide tuvastamiseks. Fowleri sõnul integreerimiskatse "harjutab alamsüsteemi kaudu kommunikatsiooniteid, et kontrollida võimalikke valesid eeldusi, kuidas igal moodulil on kaaslastega suhelda."

Integreerimistestiga testitakse tavaliselt mikroteenuse ja välisteenuste, näiteks mõne muu mikroteenuse või andmepoe, vastastikmõjusid.

Pusheri platvormi juht Pawel Ledwoń teatas mulle, et tema meeskond kaldub integreerumise testimisele. Mõne abstraktsiooni korral on ühikutestid endiselt kasulikud, kuid kasutajale suunatud funktsioonide puhul on neid süsteemi olulisi osi raske mõnitada või vahele jätta. "

Mitte kõik, kellega rääkisin, ei olnud selle protsessi fännid. Märkimist väärib näiteks Mosquera lähenemine integreerimise testimisele:

Integreerimise testimine on inimtundide osas väga veaohtlik ja kulukas. ROI-d lihtsalt pole. Iga individuaalne integreerimiskatse toob kasutusjuhtumite väikese marginaalse kajastuse.

Otsast lõpuni testimine

Viimane, kuid mitte vähem oluline on otsast lõpuni testimine, mis - nagu varem mainitud - võib olla keeruline ülesanne. Seda seetõttu, et see hõlmab mikroteenuse kõigi liikuvate osade testimist, tagades, et see suudaks saavutada teie loodud eesmärke.

Fowler kirjutas järgmise:

ots-test-testidel võib tekkida vajadus arvestada ka asünkroonsusega süsteemis, olgu see siis GUI-s või asünkroonsete taustaprotsesside tõttu teenuste vahel.

Edasi selgitab ta, kuidas need tegurid võivad põhjustada „ketendust, liigset katseaega ja testikomplekti hoolduskulusid“.

Parim nõuanne end-to-end testimise osas on piirata proovide arvu teenuse kohta. Tervislik tasakaal teiste mainitud mikroteenuste testimisstrateegiate - nagu üksuste testimine ja integreerimise testimine - vahel aitab teil väiksemaid probleeme välja rookida.

Otsast-lõpuni test on definitsiooni järgi suurem, võtab rohkem aega ja selle eksimine võib olla palju lihtsam. Kulude madalaks hoidmiseks ja ajakulu vältimiseks jääge täieliku testimise juurde, kui kõik muud testimisviisid on ammendatud, ja olge kvaliteeditagamise viimane pitser.

Mikroteenuste testimise väljakutsed

Mikroteenused (võrreldes monoliidiga) nõuavad täiendavaid samme, nagu mitme hoidla ja haru haldamine, millel kõigil on oma andmebaasiskeemid. Kuid väljakutsed võivad olla sügavamad.

Siin on mõned põhiteenused, mis on seotud mikroteenuste testimisega:

  • Kättesaadavus: Kuna erinevad meeskonnad võivad ise hallata oma mikroteenuseid, on mikroteenuse kättesaadavuse tagamine (või mis veelgi hullem, kui proovite leida aega, mil kõik mikroteenused on korraga saadaval), on karm.
  • Killustatud ja terviklik testimine: mikroteenused on loodud töötama üksi ja koos teiste lõdvalt ühendatud teenustega. See tähendab, et arendajad peavad testima kõiki komponente eraldi, samuti kõike koos.
  • Teadmiste lüngad: Eelkõige integreerimistestimise puhul (mida käsitleme edaspidi selles artiklis) peab testide läbiviijal olema tugev arusaam igast teenusest, et testjuhtumeid tõhusalt kirjutada.

Elastici Swiftype SRE juhi Oleksiy Kovyrini sõnul

Üks oluline küsimus, mida peame mikroteenustega töötades meeles pidama, on API stabiilsus ja API versioonimine. Selleks et vältida rakenduste purustamist sõltuvalt teenusest, peame veenduma, et meil on mikroteenuste API-de jaoks kindel integreerimistestide komplekt ja rikkuvate muudatuste korral peame tagama klientidele tagurpidi ühilduva viisi uuele versioonile üleminekuks versiooni omas tempos, et vältida suurte teenusteüleste API muudatuste levitamist.

Sumo Logicu peaarhitekt Stefan Zier kordas mulle samuti, et mikroteenuste testimine on tõepoolest "väga-väga raske".

"Eriti kui lähete pideva kasutuselevõtu poole. Oleme investeerinud ja investeerime jätkuvalt üsna palju integreerimise testimisse, üksuste testimisse ja teeksime palju rohkem, kui meil oleks inimesi seda tegema, ”ütles Zier mulle.

Seda öeldes tunnistas ta, et teatud etappides, kui Sumo Logic soovib nende teenuseid terviklikult testida, "saab enam-vähem kogu ettevõttest teatud mõttes kvaliteedi tagamise meeskond".

Lahendus: viis mikroteenuste testimise strateegiat alustavatele ettevõtetele

Jah, mikroteenuste testimine võib olla keeruline, kuid arvestades kõiki mikroteenuste eeliseid, ei ole nende testimisprobleemidest loobumine õige tee. Nende väljakutsete lahendamiseks sain ülevaate mitmetest CTO-dest ja destilleerisin viis strateegiat, mida nad kasutasid mikroteenuste testimiseks edukalt lähenemiseks.

1. Dokumentatsioon - esimene strateegia

Engineering Sparkposti asepresident Chris McFadden võttis meie arutelu käigus dokumentatsiooni esimese strateegia kokku üsna kenasti:

Järgime esmalt dokumentatsiooni lähenemist, nii et kogu meie dokumentatsioon on GitHubis märgistusel. Meie API dokumendid on avatud lähtekoodiga, seega on see kõik avalikud. Siis, mida me teeme, on see, enne kui keegi kirjutab mis tahes API muudatusi või kas uue API või API muudatusi, värskendab ta kõigepealt dokumentatsiooni, laseb selle muudatuse üle vaadata, veendumaks, et see vastab meie API tavadele ja standarditele, mis on kõik dokumenteeritud ja veenduge, et siin ei oleks murrangulisi muudatusi. Veenduge, et see vastaks ka meie nimetamise tavadele ja nii edasi.

Kui soovite minna veel ühe sammu edasi, võiksite uurida API lepingute testimist, mis - nagu varem mainitud - hõlmab testide kirjutamist ja käivitamist, mis tagavad, et mikroteenuse selgesõnaline ja kaudne leping toimib nii, nagu peaks.

2. Kogu korstna kastis strateegia

Täispakett kastis-strateegia hõlmab pilvekeskkonna lokaalset kopeerimist ja kõike testimist ühes hulkurlikus eksemplaris ("$ vagrant up"). Probleem? See on äärmiselt keeruline, nagu tarkvara insener Cindy Sridharan Imgixist selgitas oma blogipostituses:

Mul on selle eksituse kohta kogemus olnud eelmises ettevõttes, kus töötasin ja kus proovisime kogu oma pinu üles keerata [kohalikus] hulkurikastis. Idee, nagu võite ette kujutada, seisnes selles, et lihtne hulkur peaks võimaldama kõigil ettevõtte inseneridel (isegi esiplaanil ja mobiiliarendajatel) kogu oma sülearvutites virna keerutada.

Sridharan jätkab üksikasjalikult, kuidas ettevõttel oli ainult kaks mikroteenust, gevent-põhine API-server ja mõned asünkroonsed Pythoni tausttöötajad. Igati suhteliselt lihtne seadistus.

"Mäletan, et veetsin kogu oma esimese nädala selles ettevõttes ja üritasin VM-i kohalikult edukalt üles ehitada, et sattuda arvukate vigade hulka. Lõpuks õnnestus mul oma esimese nädala reedel kella 16.00 paiku edukalt tööle panna Vagranti seadistamine ja kõik testid läbisid kohapeal. Mäletan, et tundsin end tohutult kurnatuna, ”jutustas naine.

Lisaks selgitas Sumo Logicu peaarhitekt Stefan Zier mulle, et lisaks sellele, et seda on raske välja tõmmata, ei hõlma see lokaliseeritud testimisstrateegia lihtsalt järgmist:

"[Kohaliku kasutuselevõtu korral pakume enamikku teenuseid seal, nii et saate täielikult töötava süsteemi ja see venitab isegi 16 GB RAM-masinaid üsna kõvasti. Nii et see ei laiene tegelikult, ”sõnas ta.

3. AWS-i testimisstrateegia

See kolmas strateegia hõlmab Amazoni veebiteenuste (AWS) infrastruktuuri arendamist iga inseneri jaoks testide juurutamiseks ja käivitamiseks. See on skaleeritum lähenemisviis ülalkirjeldatud kogu pinu pakis-strateegiale.

Zier nimetas seda „isiklikuks kasutuselevõtuks [strateegiaks], kus igaühel siin on oma AWS-konto”.

"Võite lükata sülearvutis oleva koodi umbes kümne minutiga AWS-i ja käivitada see lihtsalt nagu päris süsteem," ütles ta.

4. Jagatud eksemplaride strateegia

Mulle meeldib mõelda sellest neljandast strateegiast kui hübriidist kogu pakis oleva kastis ja AWS-i testimise vahel. Seda seetõttu, et see hõlmab arendajaid, kes töötavad oma kohalikus jaamas, kasutades selleks eraldi mikroteenuse jagatud eksemplari, et testimise ajal oma kohalikku keskkonda suunata.

Scaylri inseneriosakonna juhataja Steven Czerwinski selgitas, kuidas see praktikas toimib:

Mõned [meie] arendajatest käitavad eraldi mikroteenuse eksemplari, mida kasutatakse ainult kohalike järkude testimiseks. Kujutage ette, et olete arendaja, arendate oma kohalikku tööjaama ja teil pole hõlpsat võimalust pildiparameetri käivitamiseks. Teie kohalik ehitaja osutab aga lihtsalt testkujutise parserile, mis töötab Google'i infrastruktuuris.

5. Varjatud teenuste strateegia

Ja lõpuks, meil on salajaste teenuste testimise strateegia.

Zier tutvustas SumoLogicu lähenemist teenuse testimisele, öeldes mulle, kuidas: "kirjutage nüüd need mikroteenuste märgid või" tüved ", mis käituvad nii, nagu oleksid nad õiged teenused, ja nad reklaamivad ennast meie teenuse avastuses, nagu oleksid nad tõelised teenused , kuid need on lihtsalt näiv jäljend, ”selgitas ta.

Näiteks võib teenuse testimine eeldada, et teenus saab teada, et kasutaja täidab teatud ülesandeid. Jumalateenuste abil saate teeselda, et kasutaja (ja tema ülesanded) on toimunud ilma tavapäraste keerukusteta, mis sellega kaasnevad. See lähenemisviis on palju kergem, võrreldes teenuste osutamisega tervikuna.

Tööriistad, mis aitavad teil mikroteenuseid testida

Siin on loetelu tööriistadest, mis on mulle olnud kasulikud minu enda mikroteenuste testimiskogemuse ajal, mida toetavad mõned CTO-de ja vanemate arendajate kogumi soovitused:

  • Hoverfly: simuleerib API latentsust ja tõrkeid.
  • Vagrant: ehitage ja hooldage kaasaskantavaid virtuaalse tarkvara arendamise keskkondi
  • VCR: üksuse testimise tööriist
  • Pakt: raamistab tarbijapõhiste lepingute testimise.
  • Mesila: API dokumenteerimise tööriist
  • API plaan: API ja prototüübi kujundus
  • Swagger: API-de disain ja prototüüp

Mikroteenuste testimine: keeruline, kuid seda väärt

Mikroteenuste testimine pole pargis jalutuskäik, kuid lisateenused on väärt mikroteenuste arhitektuuri eeliseid.

Lisaks peaksid mikroteenuste testimise strateegiad, nagu SumoLogic ja Scaylr, kasutusele võtma, aitavad protsessi sujuvamaks muuta. Siin on nende strateegiate kiire kokkuvõte:

  1. Dokumentatsiooni esimene strateegia
  2. Kogu paki kastis strateegia
  3. AWS-i testimisstrateegia
  4. Jagatud eksemplaride strateegia
  5. Jäme teenindusstrateegia

Loomulikult peate võib-olla iga strateegiat kohandama, et see vastaks teie ainulaadsetele oludele, kuid vanade heade katsetuste ja vigade korral peaks teie mikroteenuste testimise strateegia olema oma.

Kui teile on see artikkel meeldinud, aidake sellel allpool plaksutades levida! Sellise sisu saamiseks järgige meid Twitteris ja tellige meie ajaveeb.

Jake Lumetta on ButterCMSi tegevjuht ja avaldab Microsofti teenuseid alustavatele ettevõtetele.

Ja kui soovite oma veebisaidile lisada ajaveebi või CMS-i ilma Wordpressiga sassi ajamata, peaksite proovima Butter CMS-i.