Bez poslužitelja više je od modela izvršenja računalstva u oblaku. Mijenja način na koji planiramo, gradimo i implementiramo aplikacije. Ali to također mijenja način na koji testiramo svoje aplikacije.
Upoznajte Alexa. Alex je obični JavaScript programer, u posljednje vrijeme fokusiran na Node.js.
Posljednjih nekoliko mjeseci njegovi dobri prijatelji, Anna i Jeff, uvijek razgovaraju o toj stvari bez poslužitelja. Iako su s vremena na vrijeme dosadni, sviđa mu se ideja aplikacija bez poslužitelja. Čak je u jednom trenutku rasporedio nekoliko jednostavnih funkcija na AWS Lambda i Azure.
U nekom su trenutku Alex i njegov tim dobili novi projekt. Nakon neke analize, Alex je pomislio da bi to bilo savršeno za beskućnike. Ideju je predstavio svom timu. Neki od članova ekipe bili su uzbuđeni, jednom od njih se to nije svidjelo, ali većina nije imala čvrsto mišljenje. Stoga su odlučili pokušati - projekt nije bio prevelik, a rizik je bio nizak.
Tim je čitao o poslužiteljima bez poslužitelja i dobio je ideju kako strukturirati svoju novu aplikaciju. Ali nitko nije bio siguran kako bi se bez poslužitelja trebali uklopiti u svoj uobičajeni proces razvoja.
U tom trenutku njihov postupak izgleda ovako:
- Oni analiziraju novu značajku.
- Za manje složene značajke započinju kodom, zatim ga pokreću lokalno i na kraju dodaju neke testove.
- Za složenije značajke rade svoju verziju TDD-a: započinju s testovima, zatim pišu kôd i testiraju ga lokalno.
- Kad je značajka spremna, ide na alat CI koji je raspoređuje u testno okruženje.
- Tada QA tim uzima novu značajku za još jedan krug ručnog testiranja. Ako sve izgleda dobro, aplikacija prolazi kroz CI do produkcije.
Odlučili su krenuti korak po korak, a zatim riješiti probleme kako su se susretali s njima.
Odabrali su malu značajku, a kako je bilo jednostavno, započeli su s kodom. Kad je dio za kodiranje bio spreman, pogodili su prvu prepreku: kako lokalno pokretati aplikacije bez poslužitelja?
Lokalno testiranje
S aplikacijama bez poslužitelja ne upravljate infrastrukturom. Zvuči sjajno, ali kako onda lokalno pokrenuti svoju aplikaciju? Možete li to uopće učiniti?
Ovisno o vašoj aplikaciji i dobavljaču bez poslužitelja, neke dijelove aplikacije možete pokretati lokalno. Da biste to učinili, možete koristiti neke od sljedećih alata i tehnika:
- Osnovni alati za Azure funkcije (za Azure funkcije)
- AWS SAM CLI (za AWS Lambda aplikacije izrađene pomoću AWS SAM)
- Alati treće strane (tj. Localstack)
- docker-lambda za lokalnu simulaciju AWS Lambda
- Pokrenite funkciju Node.js lokalno
Popis naravno nije potpun - alata ima više, a nove alate vidimo gotovo svakodnevno.
Većina ovih alata ima određena ograničenja. Mogu simulirati funkcije bez poslužitelja i nekoliko drugih usluga, kao što je API Gateway. Ali što je s dopuštenjima, slojem autorizacije i ostalim uslugama?
Lokalno testiranje pomaže brzim provjerama valjanosti kako bi se osiguralo da vaša funkcija radi. No postoji li bolji način da vaša aplikacija bez poslužitelja radi kako je predviđeno? Da tamo je. Prvi i najvažniji korak je: pisanje testova.
Tako su Alex i njegov tim isprobali svoju prvu funkciju lokalno, i kako se činilo da djeluje. Zatim su prešli na sljedeći korak.
Automatizirani testovi
Alex i njegov tim upravo su se prebacili na Jest radi testiranja njihovih aplikacija Node.js. Još uvijek rade puno prednjeg dijela, pa žele koristiti iste alate za puni stog kad god mogu. Mogu li koristiti Jest i za testiranje aplikacija bez poslužitelja? I što bi trebali testirati?
Nakon brze istrage shvatili su da mogu koristiti svoje omiljene alate za testiranje Node.js. Jest, Jasmine, Mocha i drugi dobro rade s serverima.
Što biste trebali testirati u aplikaciji bez poslužitelja?
Alex i njegov tim sa svojim aplikacijama Node.js slijede trorazinsku piramidu automatizacije testa. Ispitnu piramidu prvi je put spomenuo Mike Cohn u svojoj knjizi "Uspjeh s agilnim".
Kao što test piramida definira, oni imaju:
- Puno unit testova, jer su najjeftiniji (najbrži za pisanje i izvođenje)
- Manje integracijskih testova, jer su skuplji i potrebno im je više vremena
- Nekoliko UI testova, jer su najskuplji (zahtijeva neki GUI alat) i najsporiji za pokretanje
Osim njih, oni imaju i ručno testiranje na temelju sesija, koje je obavio njihov QA tim.
Kako besposlužitelj utječe na piramidu automatizacije testa?
Odgovor ovisi o razini. Ali ispitna piramida manje nalikuje egipatskim, a više na majanske piramide.
Sloj jedinstvenih testova ne utječe puno. Jedinstveni testovi i dalje su najjeftiniji za pisanje i izvođenje, ali jedinice mogu biti manje.
Sloj za integracijske testove postaje važniji nego ikad jer se aplikacije bez poslužitelja uvelike oslanjaju na integracije. Također je jeftinije jer je posjedovanje baze podataka bez poslužitelja samo za testiranje jeftino. Dakle, u „testnoj piramidi“ bez poslužitelja morate imati više testova integracije.
Sloj za GUI testiranje je također jeftiniji i brži zbog jeftinije paralelizacije.
Ručni sloj za ispitivanje ostaje isti. Ali bez poslužitelja vam mogu pomoći da ga malo poboljšate. O tome ćemo kasnije.
Alex i njegov tim napokon su imali ideju gdje se usredotočiti. Sljedeći je problem bio kako napisati funkciju koja će ih lakše testirati.
Kako napisati provjerljive funkcije bez poslužitelja
Tijekom pisanja funkcije bez poslužitelja morate razmisliti o sljedećim rizicima:
- Rizici konfiguracije Jesu li baza podataka i tablica ispravni? Ili, imate li prava pristupa?
- Tehnički rizici tijeka radaRaščlanjujete li i upotrebljavate li dolazni zahtjev kako biste trebali? Ili, ispravno rješavate uspješne odgovore i pogreške?
- Rizici poslovne logikeJeste li slijedili sva pravila poslovne logike koja ima vaša aplikacija?
- Rizici integracije Čitate li ispravno strukturu dolaznog zahtjeva? Ili narudžbu pravilno pohranjujete u bazu podataka?
Da biste potvrdili da vaša funkcija bez poslužitelja radi ispravno, morate testirati sve ove rizike.
Možete testirati svaku od njih kao i za integracijske testove. No postavljanje i konfiguriranje usluge svaki put kada želite testirati jedan od ovih rizika nije optimalno. Kao što moj prijatelj Aleksandar Simović voli reći:
Zamislite da je ispitivanje automobila napravljeno na taj način. To bi značilo da biste svaki put kada biste htjeli testirati jedan vijak ili čak ogledalo u automobilu, morali sastaviti, a zatim rastaviti cijeli automobil.Da biste aplikaciju učinili provjerivijom, jasno je rješenje razdvojiti svoju funkciju na nekoliko manjih.
Jedan od sjajnih načina za to je primjena šesterokutne arhitekturena vaše funkcije bez poslužitelja.
Heksagonalna arhitektura, ili luke i adapteri , oblik je aplikacijske arhitekture koja promiče razdvajanje problema kroz slojeve odgovornosti. Kako objašnjava njegov tvorac Alistair Cockburn:
Omogućite da aplikaciju podjednako vode korisnici, programi, automatizirane testne ili batch skripte te da je razvijaju i testiraju izolirano od svojih eventualnih uređaja i baza podataka u toku.Pa, kako se to odnosi na funkcije bez poslužitelja?
Kako Alex i njegov tim koriste AWS, završili su sa strukturom poput sljedeće:
- Funkcija poslovna logika izlaže malo "priključaka" (ili očekuje malo argumenata). Na primjer, jedan za dolazni događaj, jedan za trajnu pohranu i jedan za obavijesti.
- Imaju dva adaptera za događaj koji pokreće funkciju, jedan za pravi AWS Lambda okidač i drugi za lokalno testiranje.
- Imaju nekoliko adaptera za trajno čuvanje i obavijesti. Na primjer, DynamoDB stolni adapter i adapter u memoriji.
Alex i njegov tim bili su sretni što su krenuli naprijed. No, prije nego što krenemo dalje, pogledajmo kako Heksagonalna arhitektura utječe na svaku razinu ispitne piramide.
Jedinstveno ispitivanje
Jedinstveni testovi ostali su isti. Ali lakše je pisati jedinične testove zbog Heksagonalne arhitekture. Jednostavno mogu koristiti lokalni adapter ili mock kao adapter za izoliranje testiranja poslovnog sloja funkcije.
Integracijsko ispitivanje
Integracijski testovi imali su velike koristi od Hexagonal Architecture. Uspjeli su u potpunosti testirati integracije koje posjeduju. Integracije trećih strana simuliraju se s drugim adapterima.
Kako to funkcionira u praksi?
Svaka od njihovih funkcija bez poslužitelja sadrži datoteke lambda.js i main.js. Glavna datoteka sadrži poslovnu logiku funkcije bez poslužitelja. A datoteka lambda.js zadužena je za povezivanje adaptera i pozivanje datoteke main.js.
Glavna datoteka ima svoje jedinice i integracijske testove. No, njegovi integracijski testovi ne testiraju potpunu integraciju s krajnjim uslugama, poput AWS S3, jer bi ih to usporilo. Umjesto toga, koriste adapter u memoriji za testiranje funkcije s integracijom pohrane datoteka.
AWS S3 integracija vrši se putem FileRepository-a , koji ima svoje jedinice i testove integracije. Provjere integracijskih testova koriste AWS S3 kako bi bili sigurni da krajnja integracija stvarno djeluje.
Za razliku od main.js , datoteka lambda.js nema testove, jer većinu vremena ima samo nekoliko redaka koda.
Ovaj je pristup sličan tehnici koju tim MindMup koristi za testiranje funkcija bez poslužitelja. Pomoću nje možete jednostavno testirati integracije svojih funkcija i pritom ubrzati integracijske testove.
GUI testiranje
Dok su Alex i njegov tim stvarali pozadinu za aplikaciju, razina GUI testova nije bila relevantna. No, kako su saznali više o bezserverima, shvatili su da bi ga mogli koristiti za poboljšanje razine GUI testova za druge aplikacije na kojima su radili.
UI testovi su skupi i spori jer se izvode u pregledniku. No, bez poslužitelja je jeftin i brzo se skalira.
Kad bi mogli pokretati preglednik u AWS Lambda, stekli bi jeftinu paralelizaciju. To bi učinilo njihove testove korisničkog sučelja jeftinijim i bržim.
Ali, možete li pokrenuti preglednik, poput Chromea, unutar funkcije bez poslužitelja?
Da! A lako je uz pomoć alata kao što su Chrome bez poslužitelja, Chromeless i Puppeteer.
Kombinacija preglednika bez poslužitelja i bez glave može nam donijeti novu generaciju alata za testiranje korisničkog sučelja. Neke od njih već možemo vidjeti i isprobati, kao što je Appraise.
CI / CD
Dok su Alex i njegov tim testirali svoju prvu funkciju bez poslužitelja, bilo je vrijeme za raspoređivanje koda u testno okruženje. To je otvorilo novo pitanje: kako mogu koristiti CI / CD alate za postavljanje svoje aplikacije bez poslužitelja?
Odgovor je jednostavan: oni mogu koristiti CI alat za pokretanje testova i postavljanje aplikacije. Da biste instalirali aplikaciju, upotrijebite bilo koji popularni alat, poput Claudia.js, AWS SAM i Framework bez poslužitelja.
I dalje možete koristiti svoj omiljeni alat za CI (poput Jenkinsa, TravisCI ili SemaphoreCI), ili ako se želite pridržavati AWS-a, možete isprobati AWS CodeBuild.
Ručno ispitivanje
Čak i putem ručnog testiranja na kojeg serveri ne utječu izravno, tim je pronašao način da poboljša svoj QA postupak.
Faze i implementacije aplikacija bez poslužitelja su jeftine i često se brzo postavljaju. Također, bez poslužitelja ne plaćate aplikaciju ako je nitko ne koristi.
To znači da posjedovanje testnog okruženja nikada nije bilo jeftinije!
Također, bez poslužitelja često možete promovirati funkciju iz jedne faze u drugu. To znači da vaš QA tim može testirati funkciju, a kada potvrde da radi, istu funkciju možete promovirati u produkciju.
Osim testiranja
Alex i njegov tim poslali su svoju prvu funkciju bez poslužitelja u pretprodukciju, a tim je bio sretan što su naučili kako testirati aplikacije bez poslužitelja.
Nastavili su koristiti server bez poslužitelja na projektu i upoznati ga s nekoliko drugih projekata. Alex se pridružio svojim prijateljima Anni i Jeffu, kao treći, ponekad dosadni propovjednik bez poslužitelja. I živjeli su sretno do kraja života.
Post-skripta
No, iako je njihova aplikacija bila dobro testirana, nešto se dogodilo preko noći.
Nakon istrage otkrili su da se jedna od integracija promijenila. Saznali su da je testiranje važno za aplikacije bez poslužitelja, ali nije dovoljno.
Kako aplikacije bez poslužitelja uvelike ovise o integracijama, rizik se prebacuje s vašeg koda na integracije. A da biste mogli uhvatiti promjene integracije i brzo reagirati, vašoj aplikaciji treba odgovarajući nadzor.
Srećom, na tržištu je svakodnevno sve više alata za nadzor bez poslužitelja. Neke od dobrih i popularnih opcija su IOpipe, Thundra, Dashbird i Epsagon.
Ali, aplikacije bez poslužitelja često imaju debelog klijenta, što znači da nadzor pozadine nije dovoljan. Trebate sličan alat za svoj prednji kraj. Ovo tržište također ima puno lijepih alata, kao što su Sentry i Rollbar.
Ali u duhu bez poslužitelja stvorili smo otvorenu aplikaciju za praćenje pogrešaka nazvanu Desole. To je aplikacija bez poslužitelja koju možete instalirati na svoj AWS račun. Omogućuje organizacijama da prate iznimke i pogreške u aplikacijama, a da ne moraju birati između pogodnosti softvera kao usluge i sigurnosti rješenja za samostalno hostiranje. Možete ga pogledati ovdje: //desole.io.
Sve ilustracije kreirane su pomoću aplikacije SimpleDiagrams4.
Ako želite saznati više o testiranju i izradi aplikacija bez poslužitelja pomoću Node.js i AWS, pogledajte "Aplikacije bez poslužitelja s Node.js", knjigu koju sam napisao s Aleksandrom Simovićem za Manning Publications:
Aplikacije bez poslužitelja s Node.js
Uvjerljiv uvod u postavljanje bez poslužitelja pomoću Claudia.js. www.manning.com
Knjiga će vas naučiti više o testiranju bez poslužitelja, s primjerima koda, ali naučit ćete i kako izgraditi i ispraviti pogreške u stvarnom svijetu API-ja bez poslužitelja (s DB-om i provjerom autentičnosti) pomoću Node i Claudia.js. I naučit ćete kako napraviti chatbotove, za Facebook Messenger i SMS (koristeći Twilio) i Alexa vještine.