Testiranje mikrousluga je teško. Preciznije, testiranje od kraja do kraja je teško, a to je nešto o čemu ćemo detaljnije razgovarati u ovom članku.
Ali prvo, brza priča.
Naučio sam koliko teško može biti testiranje mikrousluga kad sam prvi put zašao u tehnološki stog sa sedam zasebnih mikrousluga. Svaka je imala svoju bazu koda, upravljanje ovisnostima, grane značajki i shemu baze podataka - koja je također imala jedinstveni skup migracija.
Razgovarajte o užurbanom.
Pristup koji smo poduzeli bio je da se sve pokreće lokalno. Dakle, to je značilo, u bilo kojem trenutku kada želim pokrenuti testove od kraja do kraja, trebao bih proći sljedećih pet koraka za svaku od sedam mikro usluga:
- Provjerite jesam li bio na ispravnoj grani koda (master ili feature_xyz)
- Povucite najnoviji kôd za tu granu
- Osigurajte da su sve ovisnosti bile ažurne
- Pokrenite sve nove migracije baze podataka
- Pokrenite uslugu
Ovo je bio samo osnovni zahtjev kako bi se omogućilo pokretanje testova. Često bih zaboravio izvršiti jedan od ovih koraka za uslugu i potrošiti 10-15 minuta rješavajući problem. Jednom kad sam napokon usrećio i pokrenuo sve usluge, tada bih mogao započeti testiranje. Ovo me iskustvo sigurno natjeralo da propustim dane testiranja jednog velikog monolita.
Tako da, otkrio sam da je testiranje mikroservisa s kraja na kraj teško - i postaje eksponencijalno teže sa svakom novom uslugom koju predstavite. Ali ne bojte se, jer postoje načini kako olakšati testiranje mikro usluga. Razgovarao sam s nekoliko tehničkih direktora o tome kako su smislili vlastite kreativne načine rješavanja ovog složenog problema.
Uobičajene metode ispitivanja mikrousluga
Jedinstveno ispitivanje
Mikroservis po definiciji može biti manji, ali s jedinstvenim testiranjem možete postati još precizniji. Jedinstveni test fokusira se na najmanji dio testiranog softvera kako bi se utvrdilo radi li ta komponenta kako treba. Poznati softverski inženjer, autor i međunarodni govornik Martin Fowler dijeli jedinstveno testiranje u dvije kategorije:
- Društveno jedinstveno testiranje: Ova metoda jedinstvenog testiranja testira ponašanje modula promatrajući promjene u njihovom stanju.
- Ispitivanje osamljene jedinice: Ova metoda usredotočena je na interakcije i suradnju između objekta i njegovih ovisnosti, koji su zamijenjeni testnim dvojnicima.
Iako su ove strategije jedinstvenog testiranja različite, Fowler ističe da se ne natječu - mogu se koristiti zajedno za rješavanje različitih problema testiranja.
Tijekom razgovora s Davidom Straussom, tehničkim direktorom Pantheona, David mi je rekao da je "prilika da su Microservices vrlo jednostavni za stvarno provođenje unit testiranja."
Integracijsko ispitivanje
Integracijskim testovima radite ono što zvuči kao da testirate putove komunikacije i interakcije između komponenata kako biste otkrili probleme. Prema Fowleru, integracijski test "vježba putove komunikacije kroz podsustav kako bi provjerio ima li neispravnih pretpostavki koje svaki modul ima o načinu interakcije sa svojim vršnjacima."
Integracijski test obično testira interakciju između mikroservisa i vanjskih usluga, poput druge mikroservisa ili pohrane podataka.
Pawel Ledwoń, voditelj platforme u tvrtki Pusher, obavijestio me da se njegov tim "naginje prema integracijskom testiranju. Jedinstveni testovi i dalje su korisni za neke apstrakcije, ali zbog značajki okrenutih prema korisnicima teško je ismijati ili preskočiti važne dijelove sustava. "
Nisu svi s kojima sam razgovarao bili ljubitelji procesa. Na primjer, Mosquera-ini predmet integracijskog testiranja vrijedi napomenuti:
Integracijsko testiranje vrlo je sklono pogreškama i skupo je, u smislu radnog vremena. ROI jednostavno nije tamo. Svaki pojedinačni test integracije donosi malu marginalnu pokrivenost slučajeva upotrebe.Ispitivanje od kraja do kraja
Posljednje, ali ne najmanje važno, je testiranje od kraja do kraja, koje - kao što je prethodno spomenuto - može biti težak zadatak. To je zato što uključuje testiranje svakog pokretnog dijela mikroservisa, osiguravajući da može postići ciljeve zbog kojih ste ih izgradili.
Fowler je napisao sljedeće:
testovi od kraja do kraja možda će također morati uzeti u obzir asinkronost u sustavu, bilo u GUI-ju ili zbog asinkronih pozadinskih procesa između usluga.Dalje objašnjava kako ti čimbenici mogu rezultirati "nestabilnošću, pretjeranim trajanjem testa i dodatnim troškovima održavanja paketa za testiranje."
Najbolji savjet koji mogu dati kada je u pitanju testiranje od kraja do kraja jest ograničiti broj pokušaja po usluzi. Zdrava ravnoteža između ostalih spomenutih strategija testiranja mikro usluga - poput jedinstvenog testiranja i integracijskog testiranja - pomoći će vam da riješite manja pitanja.
Test od kraja do kraja po definiciji je veći, traje više vremena i može biti puno lakše pogriješiti. Da biste zadržali niske troškove i izbjegli vremenski odmak, pridržavajte se testiranja od kraja do kraja kada su svi drugi načini ispitivanja iscrpljeni i kao posljednji pečat osiguranja kvalitete.
Izazovi ispitivanja mikrousluga
Mikroservisi (u usporedbi s monolitom) zahtijevaju dodatne korake, poput upravljanja više spremišta i grana, svaki sa svojim shemama baze podataka. No izazovi mogu ići i dublje od toga.
Evo nekoliko ključnih izazova povezanih s testiranjem mikro usluga:
- Dostupnost: Budući da različiti timovi možda upravljaju vlastitim mikrouslugama, osiguravanje dostupnosti mikrousluge (ili, još gore, pokušaj pronalaska vremena kada su sve mikrousluge dostupne odjednom) je teško.
- Fragmentirano i holističko testiranje: Mikroservisi su stvoreni za rad samostalno i zajedno s ostalim slabo povezanim uslugama. To znači da programeri moraju testirati svaku komponentu u izolaciji, kao i sve zajedno.
- Praznine u znanju: Posebno kod integracijskog testiranja (koje ćemo riješiti kasnije u ovom članku), onaj tko provodi testove morat će dobro razumjeti svaku uslugu kako bi učinkovito napisao slučajeve ispitivanja.
Prema Oleksiyu Kovyrinu, voditelju Swiftype SRE-a u Elastic-u,
Jedno važno pitanje koje moramo imati na umu tijekom rada s mikrouslugama je stabilnost API-ja i izrada verzija API-ja. Da bismo izbjegli razbijanje aplikacija ovisno o usluzi, moramo biti sigurni da imamo solidan set integracijskih testova za API-je mikrousluga i, u slučaju promjene prijeloma, klijentima moramo pružiti unatrag kompatibilan način migracije na novi verziju vlastitim tempom kako bi se izbjegla velika uvođenja promjena API-ja za više usluga.Stefan Zier, glavni arhitekt u Sumo Logic, također mi je ponovio da je testiranje mikro usluga zaista "vrlo, vrlo teško".
“Pogotovo kad krenete prema kontinuiranijoj implementaciji. Ulagali smo i nastavljamo prilično ulagati u integracijsko testiranje, jedinično testiranje i učinili bismo puno više da imamo ljude koji bi to učinili ”, rekao mi je Zier.
Uz to, priznao je da, u određenim fazama, kada Sumo Logic želi cjelovito testirati svoje usluge, "više ili manje [cijela tvrtka] [postaje] tim za osiguranje kvalitete u određenom smislu."
Rješenje: Pet strategija testiranja mikroservisa za startupe
Da, testiranje mikrousluga može biti teško, ali s obzirom na sve prednosti mikrousluga, odustajanje od njih zbog izazova u testiranju nije pravi put. Kako bih se pozabavio tim izazovima, stekao sam uvid od nekoliko tehničkih direktora i destilirao pet strategija koje su koristili za uspješno pristupanje testiranju mikrousluga.
1. Dokumentacija-prva strategija
Chris McFadden, potpredsjednik Engineering Sparkposta, prilično je lijepo sažeo strategiju koja se odnosi na prvu dokumentaciju tijekom naše rasprave:
Slijedimo prvi pristup dokumentaciji, tako da je sva naša dokumentacija u GitHub-u umanjena. Naši API dokumenti su otvorenog koda, tako da su svi javni. Zatim, ono što ćemo učiniti je prije nego što bilo tko napiše bilo kakve promjene API-ja ili novi API ili promjene API-ja, prvo će ažurirati dokumentaciju, pregledati tu promjenu kako bi bili sigurni da je u skladu s našim API konvencijama i standardima koji su sve dokumentirano i pobrinite se da ovdje nije uvedena nikakva promjena. Provjerite je li u skladu s našim konvencijama imenovanja i slično.Ako ste spremni ići korak dalje, mogli biste se upustiti u API testiranje ugovora, koje - kao što je prethodno spomenuto - uključuje pisanje i pokretanje testova koji osiguravaju da eksplicitni i implicitni ugovor mikroservisa radi kako treba.
2. Strategija cijelog stoga u kutiji
Strategija cjelovitog slaganja u kutiji podrazumijeva lokalno repliciranje oblačnog okruženja i testiranje svega u jednoj skitnici (“$ vagrant up”). Problem? Izuzetno je lukav, kako je objasnila softverska inženjerka Cindy Sridharan iz Imgixa u blogu:
S ovom zabludom imao sam iskustva iz prve ruke u prethodnoj tvrtki u kojoj sam radio gdje smo pokušali zaviti cijeli svoj stog u [lokalnu] skitnicu. Ideja je, kao što biste mogli zamisliti, bila da bi jednostavno lutanje moglo omogućiti bilo kojem inženjeru u tvrtki (čak i razvojnim programerima i mobilnim programerima) da mogu u cijelosti okretati hrpu na svojim prijenosnim računalima.Sridharan nastavlja s pojedinostima kako je tvrtka imala samo dvije mikro usluge, API poslužitelj zasnovan na geventu i neke asinkrone Python pozadinske radnike. Relativno jednostavno postavljanje, bez obzira na sve.
“Sjećam se da sam cijeli prvi tjedan u ovoj tvrtki pokušavao lokalno uspješno vrtjeti VM samo da bih naišao na mnoštvo pogrešaka. Napokon, oko 16:00 sati u petak mog prvog tjedna, uspješno sam uspio pokrenuti postavku Vagranta i sve testove prolazio lokalno. Sjećam se da sam se osjećala nevjerojatno iscrpljeno ”, ispričala je.
Uz to, Stefan Zier, glavni arhitekt u Sumo Logic, objasnio mi je da se, osim što je teško izvesti, ova lokalizirana strategija testiranja jednostavno ne prilagođava:
“[S] lokalnom implementacijom tamo pokrećemo većinu usluga, tako da dobivate potpuno pokrenut sustav, a to čak prilično rasteže čak i 16 GB RAM strojeva. Dakle, to zapravo nema razmjere ”, rekao je.
3. AWS strategija testiranja
Ova treća strategija uključuje zavrtanje infrastrukture Amazon Web Services (AWS) za svakog inženjera na kojem bi se mogli implementirati i pokretati testovi. Ovo je skalabilniji pristup gore spomenutoj strategiji punog stoga u kutiji.
Zier je ovo nazvao "osobnom implementacijom [strategija], gdje svi ovdje imaju svoj vlastiti AWS račun."
"Možete gurnuti kod s vašeg prijenosnog računala u AWS za desetak minuta i jednostavno ga pokrenuti poput pravog sustava", rekao je.
4. Strategija zajedničkog testiranja
O ovoj četvrtoj strategiji volim razmišljati kao o hibridu između full stacka u kutiji i AWS testiranja. To je zato što uključuje programere koji rade na vlastitoj lokalnoj stanici, istodobno iskorištavajući zasebnu, zajedničku instancu mikrousluge na koju će usmjeravati svoje lokalno okruženje tijekom testiranja.
Steven Czerwinski, voditelj inženjeringa, Scaylr, objasnio je kako to može funkcionirati u praksi:
Neki [naši] programeri pokreću zasebnu instancu mikrousluge samo da bi se koristili za testiranje lokalnih gradnji. Dakle, zamislite da ste programer, razvijate se na lokalnoj radnoj stanici i nemate jednostavan način pokretanja parsera za slike. Međutim, vaš lokalni graditelj samo bi ukazao na probni parser slika koji je pokrenut u Googleovoj infrastrukturi.5. Stubed strategija usluga
I na kraju, imamo zamućenu strategiju testiranja usluga.
Zier je izložio SumoLogićev pristup testiranju zakrčenih usluga rekavši mi kako, "stubbing da vam napišemo ove oznake ili 'klice' mikroservisa koji se ponašaju kao da su prava usluga i oglašavaju se u našem otkriću usluga kao da su stvarna usluga , ali oni su samo glupa imitacija ”, objasnio je.
Na primjer, testiranje usluge može zahtijevati da usluga postane svjesna da korisnik izvršava skup zadataka. Kružnim uslugama možete se pretvarati da se korisnik (i njegovi zadaci) odvijali bez uobičajenih složenosti koje uz to dolaze. Ovaj je pristup puno lakši u odnosu na pokretanje usluga u cjelini.
Alati koji će vam pomoći da testirate mikrousluge
Evo popisa alata koji su mi koristili tijekom mog vlastitog iskustva s testiranjem mikroservisa, potkrijepljenih nekim preporukama iz grupe CTO-a i starijih programera:
- Hoverfly: simulira kašnjenje i kvarove API-ja.
- Vagrant: izradite i održavajte prijenosna okruženja za razvoj virtualnog softvera
- VCR: alat za jedinstveno testiranje
- Pakt: okviri testiranja ugovora vođenih potrošačima.
- Apiary: Alat za dokumentaciju API-ja
- Nacrt API-ja: dizajn i prototip API-ja
- Swagger: API i dizajn prototipa
Ispitivanje mikrousluga: teško, ali vrijedi
Testiranje vaših mikroservisa neće biti šetnja parkom, ali dodatni posao vrijedan je prednosti arhitekture mikroservisa.
Uz to, strategije testiranja mikrousluga koje su usvojili poput SumoLogic i Scaylr trebale bi pomoći u izglađivanju procesa. Evo kratkog sažetka tih strategija:
- Dokumentacija-prva strategija
- Strategija cijelog stoga u kutiji
- Strategija testiranja AWS
- Strategija zajedničkih primjera testiranja
- Zakrčena strategija usluge
Prirodno, možda ćete trebati doraditi svaku strategiju kako bi odgovarala vašim jedinstvenim okolnostima, ali uz neka dobra staromodna pokušaja i pogreške, vaša strategija testiranja mikro usluga trebala bi doći na svoje.
Ako vam se svidio ovaj članak, pomozite mu da se proširi pljeskajući u nastavku! Za više ovakvih sadržaja, pratite nas na Twitteru i pretplatite se na naš blog.
Jake Lumetta izvršni je direktor tvrtke ButterCMS i objavljuje Microservices za startupe.
A ako želite dodati blog ili CMS na svoje web mjesto bez petljanja s Wordpressom, trebali biste isprobati Butter CMS.