Paras tapa testata palvelimettomia sovelluksia

Palvelimeton on enemmän kuin pilvipalvelujen suoritusmalli. Se muuttaa tapaa suunnitella, rakentaa ja ottaa käyttöön sovelluksia. Mutta se muuttaa myös tapaa, jolla testaamme sovelluksiamme.

Tapaa Alex. Alex on tavallinen JavaScript-kehittäjä, keskittynyt Node.js: ään viime aikoina.

Viimeisten parin kuukauden aikana hänen hyvät ystävänsä, Anna ja Jeff, puhuvat aina palvelimettomasta asiasta. Jopa niiden kautta, jotka ovat ajoittain ärsyttäviä, hän pitää ajatuksesta palvelimettomista sovelluksista. Hän jopa asetti muutamia yksinkertaisia ​​toimintoja AWS Lambdaan ja Azureen jossain vaiheessa.

Jossain vaiheessa Alex ja hänen tiiminsä saivat uuden projektin. Jonkin analyysin jälkeen Alex ajatteli, että se sopisi täydellisesti palvelimettomaan. Hän esitteli idean tiimilleen. Jotkut tiimin jäsenistä olivat innoissaan, yksi heistä ei pitänyt siitä, mutta useimmilla heistä ei ollut vahvaa mielipidettä. Joten he päättivät kokeilla sitä - projekti ei ollut liian iso, ja riski oli pieni.

Tiimi luki palvelimettomasta ja sai idean uuden sovelluksen rakentamisesta. Mutta kukaan ei ollut varma, kuinka heidän pitäisi sopia palvelimettomaksi yhteiseen kehitysprosessiin.

Sillä hetkellä heidän prosessinsa näyttää tältä:

  1. He analysoivat uuden ominaisuuden.
  2. Vähemmän monimutkaisille ominaisuuksille he aloittavat koodilla, sitten ajavat sen paikallisesti ja lisäävät lopulta joitain testejä.
  3. Monimutkaisempia ominaisuuksia varten he tekevät TDD-versionsa: he aloittavat testeillä, kirjoittavat koodin ja testaavat sen paikallisesti.
  4. Kun ominaisuus on valmis, se menee CI-työkaluun, joka ottaa sen käyttöön testausympäristössä.
  5. Sitten laadunvarmistusryhmä ottaa uuden ominaisuuden uudelle manuaalisen testauksen kierrokselle. Jos kaikki näyttää hyvältä, sovellus menee CI: n kautta tuotantoon.

He päättivät aloittaa askel askeleelta ja sitten ratkaista ongelmat heidän kohdatessaan.

He valitsivat pienen ominaisuuden, ja koska se oli yksinkertaista, he alkoivat koodilla. Kun koodausosa oli valmis, he osuivat ensimmäiseen estoon: miten suoritat palvelimettomia sovelluksia paikallisesti?

Paikallinen testaus

Palvelimettomilla sovelluksilla et hallitse infrastruktuuria. Kuulostaa hyvältä, mutta miten suoritat sitten sovelluksesi paikallisesti? Voitko edes tehdä sen?

Sovelluksesta ja palvelimettomasta toimittajasta riippuen voit suorittaa joitain sovelluksen osia paikallisesti. Voit tehdä tämän käyttämällä joitain seuraavista työkaluista ja tekniikoista:

  • Azure Functions -työkalut (Azure-toiminnoille)
  • AWS SAM CLI (AWS SAM: lla rakennettuihin AWS Lambda -sovelluksiin)
  • Kolmannen osapuolen työkalut (ts. Localstack)
  • docker-lambda AWS Lambda -paikallissimulaatioon
  • Suorita Node.js-toiminto paikallisesti

Luonnollisesti luettelo ei ole täydellinen - työkaluja on enemmän, ja näemme uusia työkaluja melkein joka päivä nyt.

Suurimmalla osalla näistä työkaluista on tiettyjä rajoituksia. Ne voivat simuloida palvelimettomia toimintoja ja muutamia muita palveluita, kuten API Gateway. Mutta entä käyttöoikeudet, todennustaso ja muut palvelut?

Paikallinen testaus auttaa nopeissa tarkistuksissa varmistamaan, että toimintosi toimii. Mutta onko olemassa parempi tapa varmistaa, että palvelimeton sovellus toimii tarkoitetulla tavalla? Kyllä on. Ensimmäinen ja tärkein vaihe on: testien kirjoittaminen.

Joten Alex ja hänen tiiminsä kokeilivat ensimmäistä toimintaansa paikallisesti, ja koska se näytti toimivan. Sitten he menivät seuraavaan vaiheeseen.

Automaattiset testit

Alex ja hänen tiiminsä siirtyivät juuri Jestiin testaamaan Node.js-sovelluksiaan. He tekevät edelleen paljon käyttöliittymää, joten he haluavat käyttää samoja työkaluja koko pinoon aina kun pystyvät. Voivatko he käyttää Jestiä myös palvelimettomien sovellusten testaamiseen? Ja mitä heidän pitäisi testata?

Nopean tutkinnan jälkeen he tajusivat voivansa käyttää suosikki Node.js -testaustyökalujaan. Jest, Jasmine, Mocha ja muut toimivat hyvin palvelimettomien kanssa.

Mitä sinun pitäisi testata palvelimettomassa sovelluksessa?

Alex ja hänen tiiminsä seuraavat Node.js-sovelluksillaan kolmitasoista testiautomaatiopyramidia. Testipyramidin mainitsi ensimmäisen kerran Mike Cohn kirjassaan "Ketterän menestyminen".

Kuten testipyramidi määrittelee, heillä on:

  • Paljon yksikkötestejä, koska ne ovat halvimpia (nopein kirjoittaa ja suorittaa)
  • Vähemmän integraatiotestejä, koska ne ovat kalliimpia, ja niiden suorittaminen vie enemmän aikaa
  • Muutama käyttöliittymätesti, koska ne ovat kalleimpia (vaatii jonkin GUI-työkalun) ja hitaimmin suoritettavia

Näiden lisäksi heillä on myös manuaalinen istuntoon perustuva testaus, jonka tekee heidän laadunvalvontaryhmänsä.

Kuinka palvelimeton vaikuttaa testiautomaatiopyramidiin?

Vastaus riippuu tasosta. Mutta testipyramidi näyttää vähemmän kuin egyptiläiset pyramidit ja enemmän kuin mayojen pyramidit.

Yksikkötestikerrokseen ei vaikuta paljon. Yksikkötestit ovat edelleen halvimpia kirjoittaa ja suorittaa, mutta yksiköt voivat olla pienempiä.

Integraatiotestikerroksesta tulee tärkeämpi kuin koskaan, koska palvelimettomat sovellukset luottavat vahvasti integraatioihin. Se on myös halvempaa, koska palvelimettoman tietokannan pitäminen vain testausta varten on halpaa. Joten palvelimettomassa "testipyramidissa" sinulla on oltava enemmän integraatiotestejä.

GUI-testikerros on myös halvempi ja nopeampi halvemman rinnakkaistamisen takia.

Manuaalinen testaustaso pysyy samana. Mutta palvelimeton voi auttaa parantamaan sitä hieman. Mennään yksityiskohtiin siitä myöhemmin.

Alexilla ja hänen tiimillään oli vihdoin idea, mihin keskittyä. Seuraava ongelma oli kuinka kirjoittaa funktio testata niitä helpommin.

Testattavien palvelimettomien toimintojen kirjoittaminen

Sinun tulee miettiä seuraavia riskejä kirjoittaessasi palvelintoimintoa:

  • Määritysriskit Ovatko tietokanta ja taulukko oikein? Vai onko sinulla käyttöoikeuksia?
  • Tekniset työnkulun riskitJäsennätkö ja käytätkö saapuvaa pyyntöä kuten pitäisi? Vai käsitteletkö onnistuneita vastauksia ja virheitä oikein?
  • LiikelogiikkariskitNoudatitko kaikkia sovelluksesi liiketoimintalogiikkasääntöjä?
  • Integrointiriskit Luetko saapuvan pyynnön rakennetta oikein? Vai tallennatko tilauksen oikein tietokantaan?

Sinun on testattava kaikki nämä riskit varmistaaksesi, että palvelimeton toiminto toimii oikein.

Voit testata näitä kaikkia samalla tavalla kuin integraatiotestejä varten. Mutta palvelun määrittäminen ja määrittäminen aina, kun haluat testata jotakin näistä riskeistä, ei ole optimaalinen. Kuten ystäväni Aleksandar Simovic rakastaa sanoa:

Kuvittele, onko autojen testaus tehty tällä tavalla. Tämä tarkoittaisi, että joka kerta, kun haluat testata yhtä ruuvia tai jopa peiliä autossa, sinun on koottava ja purettava sitten koko auto.

Jotta sovellus olisi testattavampi, selkeä ratkaisu on jakaa toimintosi useiksi pienemmiksi.

Yksi hieno tapa tehdä se on kuusikulmaisen arkkitehtuurin soveltaminenpalvelintoimintoihin.

Kuusikulmainen arkkitehtuuri eli Ports and Adapters on sovellusarkkitehtuurin muoto, joka edistää huolen erottamista vastuun kerrosten kautta. Sen luoja Alistair Cockburn selittää:

Anna sovelluksen ohjata yhtä lailla käyttäjiä, ohjelmia, automaattisia testi- tai komentosarjoja, ja se voidaan kehittää ja testata erillään sen mahdollisista ajonaikaisista laitteista ja tietokannoista.

Joten miten se pätee palvelimettomiin toimintoihin?

Kun Alex ja hänen tiiminsä käyttävät AWS: ää, heillä oli seuraavanlainen rakenne:

  • Funktion liiketoimintalogiikka paljastaa muutaman “portin” (tai odottaa muutaman argumentin). Esimerkiksi yksi saapuvaan tapahtumaan, yksi pysyvään tallennukseen ja toinen ilmoituksiin.
  • Heillä on kaksi sovitinta tapahtumaa varten, joka laukaisee toiminnon, yksi todelliselle AWS Lambda -liipaisimelle ja toinen paikallista testausta varten.
  • Heillä on useita sovittimia pysyvään varastointiin ja ilmoituksiin. Esimerkiksi DynamoDB-pöytäadapteri ja muistinsovitin.

Alex ja hänen tiiminsä olivat onnellisia, että he etenivät eteenpäin. Mutta ennen kuin siirrymme eteenpäin, katsotaanpa, kuinka kuusikulmainen arkkitehtuuri vaikuttaa testipyramidin jokaiseen tasoon.

Yksikkötestaus

Yksikkötestit pysyivät ennallaan. Mutta yksikkötestejä on helpompi kirjoittaa kuusikulmaisen arkkitehtuurin takia. He voivat yksinkertaisesti käyttää paikallista sovitinta tai pilkkoa sovittimena toimintokerroksen testaamiseen erillään.

Integraation testaus

Integraatiotestit hyötyivät paljon kuusikulmaisesta arkkitehtuurista. He pystyivät testaamaan täysin omistamansa integraatiot. Kolmansien osapuolten integraatioita simuloidaan muiden sovittimien kanssa.

Kuinka se toimii käytännössä?

Jokaisella palvelimettomalla toiminnolla on lambda.js- ja main.js- tiedostot. Päätiedosto sisältää palvelimettoman toiminnon liiketoimintalogiikan. Ja lambda.js- tiedosto vastaa sovittimien johdotuksesta ja main.js- tiedoston kutsumisesta .

Päätiedostolla on oma yksikkö ja integraatiotestit. Mutta sen integraatiotestit eivät testaa täydellistä integraatiota loppupalveluiden, kuten AWS S3: n kanssa, koska se hidastaa niitä. Sen sijaan he käyttävät muistisovitinta testatakseen toiminnon tiedostotallennusintegraatiolla.

AWS S3 -integrointi tapahtuu FileRepositoryn kautta , jolla on oma yksikkö ja integraatiotestit. Integraatiotestitarkistukset käyttävät AWS S3: ta varmistaakseen, että lopullinen integraatio todella toimii.

Toisin kuin main.js , lambda.js- tiedostossa ei ole testejä, koska sillä on yleensä muutama koodirivi.

Tämä lähestymistapa on kuin tekniikka, jota MindMup-tiimi käyttää palvelimettomien toimintojen testaamiseen. Sen avulla voit helposti testata toimintojesi integraatioita ja nopeuttaa integraatiotestejäsi.

GUI-testaus

Kun Alex ja hänen tiiminsä rakensivat sovelluksen takaosaa, GUI-testitaso ei ollut merkityksellinen. Mutta kun he oppivat lisää palvelimettomasta, he tajusivat voivansa käyttää sitä parantamaan GUI-testitasoa muille sovelluksille, joita he työskentelivät.

Käyttöliittymätestit ovat kalliita ja hitaita, koska ne suoritetaan selaimessa. Mutta palvelimeton on halpaa ja se skaalautuu nopeasti.

Jos he pystyisivät käyttämään selainta AWS Lambdassa, he saisivat halvan rinnakkaisuuden. Se tekisi niiden käyttöliittymätestit halvemmiksi ja nopeammin.

Mutta voitko käyttää selainta, kuten Chromea, palvelimettoman toiminnon sisällä?

Joo! Ja se on helppoa sellaisten työkalujen avulla kuin Serverless Chrome, Chromeless ja Puppeteer.

Palvelimettomien ja päätöttömien selainten yhdistelmä voi tuoda meille uuden sukupolven käyttöliittymän testaustyökaluja. Voimme jo nähdä ja kokeilla joitain niistä, kuten Appraise.

CI / CD

Kun Alex ja hänen tiiminsä testasivat ensimmäisen palvelimettoman toiminnon, oli aika ottaa koodi käyttöön testausympäristössä. Se herätti uuden kysymyksen: kuinka he voivat käyttää CI / CD-työkaluja palvelimettoman sovelluksensa käyttöönottoon?

Vastaus on yksinkertainen: he voivat käyttää CI-työkalua testien suorittamiseen ja sovelluksen käyttöönottoon. Voit ottaa sovelluksen käyttöön käyttämällä mitä tahansa suosittua työkalua, kuten Claudia.js, AWS SAM ja Serverless Framework.

Voit silti käyttää suosikki CI-työkalua (kuten Jenkins, TravisCI tai SemaphoreCI), tai jos haluat pysyä kiinni AWS: stä, voit kokeilla AWS CodeBuildia.

Manuaalinen testaus

Palvelimettomat eivät vaikuta suoraan manuaaliseen testaukseen, joukkue löysi keinon parantaa QA-prosessiaan.

Palvelimettoman sovelluksen vaiheet ja käyttöönotot ovat halpoja ja usein nopeasti asennettavia. Palvelimettomana et myöskään maksa sovelluksesta, jos kukaan ei käytä sitä.

Tämä tarkoittaa, että testausympäristön käyttäminen ei ole koskaan ollut halvempaa!

Palvelimettomalla voit myös usein mainostaa toimintoa vaiheesta toiseen. Tämä tarkoittaa, että laaduntarkastusryhmäsi voi testata toimintoa, ja kun he vahvistavat, että se toimii, voit mainostaa samaa toimintoa tuotantoon.

Testauksen lisäksi

Alex ja hänen tiiminsä toimittivat ensimmäisen palvelimettoman toiminnon esituotantoon, ja joukkue oli iloinen siitä, että he oppivat testaamaan palvelimettomia sovelluksia.

He jatkoivat palvelimetonta käyttöä projektissa ja esittivät sen muutamalle muulle projektille. Alex liittyi ystäviensä Anna ja Jeffin joukkoon kolmantena, toisinaan ärsyttävänä palvelimettomana saarnaajana. Ja he elivät onnellisina elämänsä loppuun asti.

Jälkikirjoitus

Mutta vaikka heidän sovelluksensa oli hyvin testattu, jotain tapahtui yhdessä yössä.

Tutkimuksen jälkeen he huomasivat, että yksi integraatioista muuttui. He oppivat, että testaus on tärkeää palvelimettomille sovelluksille, mutta se ei riitä.

Koska palvelimettomat sovellukset riippuvat suuresti integraatioista, riski siirtyy koodistasi integraatioihin. Ja jotta sovelluksesi voi saada kiinni integraatiomuutoksista ja reagoida nopeasti, sovellustasi on valvottava asianmukaisesti.

Onneksi markkinoilla on päivittäin yhä enemmän palvelimettomia valvontatyökaluja. Jotkut hyvistä ja suosituista vaihtoehdoista ovat IOpipe, Thundra, Dashbird ja Epsagon.

Mutta palvelimettomilla sovelluksilla on usein paksu asiakas, mikä tarkoittaa, että taustapään seuranta ei riitä. Tarvitset samanlaisen työkalun käyttöliittymään. Myös näillä markkinoilla on paljon mukavia työkaluja, kuten Sentry ja Rollbar.

Mutta palvelimettomuuden hengessä loimme avoimen lähdekoodin virheiden seurantasovelluksen nimeltä Desole. Se on palvelimeton sovellus, jonka voit asentaa AWS-tilillesi. Sen avulla organisaatiot voivat seurata sovellusten poikkeuksia ja virheitä tarvitsematta valita ohjelmistopalvelun mukavuuden ja itse isännöidyn ratkaisun turvallisuuden välillä. Voit tarkistaa sen täältä: //desole.io.

Kaikki kuvat on luotu SimpleDiagrams4 -sovelluksella.

Jos haluat oppia lisää palvelimettomien sovellusten testaamisesta ja rakentamisesta Node.js: n ja AWS: n avulla, tutustu Aleksandar Simovicin kanssa kirjoittamaan kirjaan "Serverless Applications with Node.js":

Palvelimettomat sovellukset Node.js: n kanssa

Pakottava esittely palvelimettomiin käyttöönottoihin Claudia.js: n avulla. www.manning.com

Kirja opettaa sinulle lisää palvelimettomasta testauksesta koodiesimerkkien avulla, mutta opit myös rakentamaan ja virittämään todellisen palvelimettoman sovellusliittymän (DB: llä ja todennuksella) Node- ja Claudia.js-tiedostoilla. Ja opit rakentamaan chatrobotteja Facebook Messengerille ja tekstiviesteille (Twilion avulla) ja Alexa-taidoille.