så här testar du dina webbappar
i mjukvaruindustrin testar alla sina applikationer på något sätt. Många utvecklarteam har utarbetade testscheman som är väl integrerade med sina kontinuerliga integrationsrörledningar, men även de som inte har automatiska tester måste fortfarande komma på sätt att kontrollera att deras kod fungerar som avsett.
att bygga en webbplats och klicka igenom den manuellt med hjälp av en webbläsare är en mängd olika tester. Även om det inte är den mest sofistikerade, räknas det fortfarande. Detsamma gäller för att skjuta upp cURL i konsolen och skicka en syntetisk begäran till API-slutpunkten du just skapade.
det här inlägget kommer att diskutera hur man automatiserar den manuella testningen vi redan gör innan vi dyker in i olika testtyper och metoder.
automatisera tester
manuella tester är tillräckliga för små appar, men när dessa appar växer växer deras testbara yta med dem, vilket orsakar två problem.
en, när människor måste utföra tester varje gång en ny version av en app är klar kan inkonsekvenser uppstå. Detta gäller särskilt om det finns många tester. För det andra kan personen som gör testerna inte utföra andra uppgifter. Med stora appar kan testning ta flera dagar.
det mest logiska sättet att lösa dessa två problem är att automatisera dessa manuella uppgifter. Två huvudtyper av tester finns för webbappar: UI-tester och API-tester. Två verktyg kan automatisera dem.
UI-tester
UI-tester kan utföras med ett verktyg som heter Puppeteer. Puppeteer låter dig automatisera ett manuellt UI-test med JavaScript. Den installeras via NPM med följande kommando:
$ npm i puppeteer
du kan sedan skriva ett skript som styr en huvudlös version av Chrome för att köra dina tester. Detta skript kan se ut som följande:
(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();
i det här skriptet startar vi en huvudlös instans av Chrome och navigerar till example.com, och letar efter ett H1-element. Om det inte finns loggas ett felmeddelande.
API-tester
API-tester kan automatiseras via Postman. Postman levereras med ett grafiskt gränssnitt för att bygga HTTP-förfrågningar som kan sparas. Dessa förfrågningar kan utföras senare med bara ett musklick.
för att komma igång, ladda ner och installera Postman UI. Följande steg behövs för att skapa och spara en begäran:
- klicka på Skapa en samling till vänster
- skriv in min samling som samlingsnamn
- klicka på Skapa
- klicka på ellipsen (…) i min samling till vänster
- välj Lägg till begäran
- skriv in min begäran som förfrågningsnamn
- klicka på Spara i min samling
begäran visas i den vänstra sidofältet under din nyskapade samling.
om du väljer det måste du ange example.com som en URL och Lägg till ett test. För att lägga till ett test, klicka på test i flikfältet under URL-inmatningsfältet.
ett textområde där du kan skriva ditt test i JavaScript visas. Följande är ett exempel på ett test:
pm.test("Status code is 200", () => { pm.response.to.have.status(200);});
om du klickar på Spara längst upp till höger på skärmen och skickar direkt efter det skickas din begäran. Testskriptet körs sedan för att avgöra om svaret hade status 200 eller inte.
typer av tester
det finns tre olika typer av tester. Att förstå dem kan du välja rätt typ av testning för de olika delarna av din programvara stack.
enhetstester
enhetstester är den enklaste typen av test. De kontrollerar korrektheten av små delar av din kod. Ett enhetstest täcker vanligtvis ett samtal till en funktion eller ett sätt att använda en klass.
ett enhetstest är vanligtvis den första” användaren ” av din kod. Vissa testmetoder kräver till och med att du skriver testet innan implementeringen av den faktiska applikationskoden.
enhetstester kan användas i både backend och frontend utveckling. Vissa utvecklingsteam använder enhetstester för att kontrollera den renderade DOM-utmatningen av små delar av sin kod, som formulär eller menyer. I backend används ofta enhetstester för att testa koden mellan HTTP-servern och databasen eller andra API: er.
tre allmänt använda testlöpare för enhetstester är:
‐ Jest—Jest används mest i frontend-utveckling eftersom det kommer med unika funktioner, som snapshot-testning, som hjälper till med problem som UI-regressioner. En Jest tutorial kan hittas här.
om ett enhetstest kräver några externa resurser, som nätverksanslutningar eller databaser, skriver du förmodligen ett integrationstest. Denna typ av test täcks nästa.
integrationstester
ur ett implementeringsperspektiv ser integrationstester ut som enhetstester. Skillnaden är att integrationstester testar flera delar av stapeln tillsammans. De kan till exempel testa om klienten och servern talar samma protokoll eller, i en mikroservicearkitektur, om tjänsterna fungerar korrekt tillsammans eller inte.
kontroller som vanligtvis skulle hamna i flera oberoende enhetstester kan aggregeras till ett integrationstest som avgör om allt fungerar bra tillsammans.
integrationstester används i både frontend och backend utveckling. De används ibland för att se om de två delarna interagerar korrekt, men de kan också användas för att avgöra om olika moduler i en del arbetar tillsammans som avsedda.
du kan använda samma testlöpare för integrationstester som du använde för enhetstester. Men Postman, UI-verktyget som används ovan för att automatisera manuella API-tester, kommer också med ett CLI-verktyg som heter Newman som kan integreras med din CI/CD-pipeline.
Newman kan köra exporterade Postman samlingar, så att du kan skapa förfrågningar och tester med Postman UI och köra dem senare via CLI. En Newman handledning kan hittas här.
om ett integrationstest kräver interaktion med användargränssnittet kallas det ett UI—test-adresserat nästa.
UI-tester
UI-tester är de mest sofistikerade testerna. De försöker efterlikna användarnas beteende på ett automatiserat sätt så att testare inte behöver klicka igenom alla delar av deras app manuellt.
UI-tester hjälper ofta till att fånga en specifik interaktion som ledde till ett fel för en användare. När den har tagits kan den reproduceras med ett klick för att fixa felet och förhindra att det kommer tillbaka i en ny version.
Jest-och AVA-testlöparna som nämnts tidigare kan användas här, men du behöver vanligtvis ett extra bibliotek för att underlätta användargränssnittet via en webbläsare. De två huvudbiblioteken som för närvarande används för denna process är:
‐ Puppeteer—Puppeteer är ett JavaScript-bibliotek som levereras med en huvudlös implementering av Chrome som gör det möjligt att köra UI-tester programmatiskt i bakgrunden. En Marionetthandledning finns här.
det finns fler typer av tester än de som anges här. Andra kan ha olika mål; till exempel försöker lasttester hitta flaskhalsar i prestanda. Tänk på att de tester som beskrivs här ibland ges olika namn. De tre typerna som presenteras ovan är de viktigaste att implementera när du kommer igång. Att använda en av dem är bättre än att inte använda någon automatiserad testning alls.
testmetoder
testmetoder är sätt att tänka på testning. De tre som beskrivs nedan är de vanligaste.
testdriven utveckling (TDD)
TDD är den mest använda metoden och den mest tekniska. Det rekommenderar att du skriver dina tester innan du skriver den faktiska koden som du vill testa. Eftersom du måste skriva ett test för endast den del av koden du implementerar är den typ av test du skriver ett enhetstest.
enhetstester är ganska granulära, så med tiden resulterar användningen av denna metod i ackumulering av många test. Denna verklighet, i kombination med det faktum att nybörjare TDD-utövare tenderar att skriva triviala tester, kan leda till skapandet av en hög med värdelösa tester. För att undvika detta är det viktigt att uppdatera och städa upp tester när teamet har blivit mer bekant med TDD och med testning i allmänhet.
det är viktigt att köra testerna ofta, inte bara i en CI/CD-pipeline, men också lokalt på din utvecklingsmaskin. Skriv ett test, kör det, se det misslyckas, implementera tillräckligt för att testet ska passera och upprepa processen.
för vidare läsning, kolla in Agile Alliances beskrivning av TDD.
Acceptance Test Driven Development (ATDD)
ATDD är en modifiering av TDD som fokuserar mer på affärsfall och mindre på teknisk implementering. Testtyperna som används i denna metod är mestadels integrationstester, eftersom ofta flera delar av systemet måste användas tillsammans för att lösa ett affärsbehov.
eftersom testerna är mindre tekniska, är det också lämpligt att inkludera icke-tekniskt orienterade personer i testprocessen. Produktägare och kunder kan hjälpa till att definiera affärsfall så att en utvecklare kan skriva ett test för dem. Om testet inte kan köras framgångsrikt är det tydligt att mer funktionalitet måste implementeras.
ATDD fungerar på en annan abstraktionsnivå än TDD, så de två metoderna kan användas tillsammans.
för vidare läsning, kolla in Agile Alliances beskrivning av TDD.
Behavior Driven Development (BDD)
BDD är en blandning av TDD och ATDD, och målet är att använda det bästa av två världar för att göra det övergripande systemet mer stabilt. BDD försöker specificera ett system med tester som illustrerar dess användning.
precis som ATDD försöker BDD fånga affärsfall. Men det kräver också att du ifrågasätter dessa användningsfall med” 5 whys “eftersom” whys ” är en saknad del i ATDD. Visst är det bättre att fråga kunderna vad de vill ha istället för att förlita sig enbart på utvecklarinmatning. Men det är också viktigt att ifrågasätta antagandena från båda dessa grupper.
BDD är också en blandning av TDD och ATDD i betydelsen abstraktionsnivåer. TDD testar bara de små delarna av din ansökan och ATDD testar bara hur dessa delar fungerar tillsammans. BDD kräver att du tillämpar denna metod på den stora hela din app och dess små delar, vilket gör BDD till en mer helhetssyn på testning.
för vidare läsning, kolla in Agile Alliances beskrivning av BDD.
slutsats
även om ingen testning är hemsk, är manuell testning bättre och automatiserad testning är bäst.
beroende på storleken på din app kan ett manuellt test blockera medlemmar i utvecklingsteamet från att arbeta med andra projekt i dagar eller till och med veckor, vilket kostar ditt företag tid och pengar. Dessutom kan den monotona uppgiften att utföra samma interaktioner om och om igen leda till glider som ofta manifesterar sig i ofångade buggar.
datorer är mycket bra på att upprepa samma uppgift om och om igen, så det är bra att delegera testning till ett skript och frigöra dina utvecklares tid. Om dessa tester är integrerade i din CI/CD-pipeline kan de redan skrivna testerna bara köras implicit när ett nytt åtagande landar i dina förvar.
det är bra att använda en testmetodik tidigt, eftersom de stora problemen när man kommer igång ofta är “vad” och “när” att testa. Dessa metoder kan hjälpa till att klargöra en process som gör skrivprov mer konsekventa för alla medlemmar i teamet.
Leave a Reply