Sådan testes dine Internetapps

i programindustrien tester alle deres applikationer på en eller anden måde. Mange udviklerteam har detaljerede testordninger, der er godt integreret med deres kontinuerlige integrationsledninger, men selv dem, der ikke har automatiske test, skal stadig komme med måder at kontrollere, at deres kode fungerer som beregnet.

opbygning af en hjemmeside og klikke gennem det manuelt ved hjælp af en bro.ser er en bred vifte af test. Selvom det ikke er den mest sofistikerede, tæller det stadig. Det samme gælder for at skyde cURL i konsollen og sende en syntetisk anmodning til API-slutpunktet, du lige har oprettet.

dette indlæg vil diskutere, hvordan man automatiserer den manuelle test, vi allerede gør, før vi dykker ned i forskellige testtyper og metoder.

Automatiseringstest

manuelle test er tilstrækkelige til små apps, men når disse apps vokser, vokser deres testbare overflade med dem og forårsager to problemer.

en, når folk skal udføre tests, hver gang en ny version af en app er færdig, kan der opstå uoverensstemmelser. Dette gælder især, hvis der er mange tests. To, den person, der udfører testene, kan ikke udføre andre opgaver. Med store apps kan test tage flere dage.

den mest logiske måde at løse disse to problemer på er at automatisere disse manuelle opgaver. Der findes to hovedtyper af test for internet-apps: UI-test og API-test. To værktøjer kan automatisere dem.

UI test

UI test kan udføres med et værktøj kaldet Puppeteer. Puppeteer giver dig mulighed for at automatisere en manuel UI-test ved hjælp af JavaScript. Den installeres via NPM med følgende kommando:

 $ npm i puppeteer

du kan derefter skrive et script, der styrer en hovedløs version af Chrome for at køre dine tests. Dette script kunne se ud som følgende:

(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 dette script starter vi en hovedløs forekomst af Chrome, der navigerer til example.com, og leder efter et H1-element. Hvis den ikke findes, logges en fejlmeddelelse.

API-test

API-test kan automatiseres via postbud. Postman leveres med en grafisk grænseflade til opbygning af HTTP-anmodninger, der kan gemmes. Disse anmodninger kan udføres senere med blot et museklik.

for at komme i gang, hente og installere Postman UI. Følgende trin er nødvendige for at oprette og gemme en anmodning:

1. Klik på Opret en samling til venstre
2. indtast min samling som samlingsnavn
3. Klik på Opret
4. Klik på ellipsen (…) i min samling til venstre
5. vælg Tilføj anmodning
6. indtast min anmodning som anmodningsnavn
7. Klik på Gem i min samling

anmodningen vises i venstre sidepanel under din nyoprettede samling.

hvis du vælger det, skal du indtaste example.com som en URL og tilføj en test. For at tilføje en test skal du klikke på Tests i fanebladet under URL-indtastningsfeltet.

et tekstområde, hvor du kan skrive din test i JavaScript, vises. Følgende er et eksempel på en test:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

hvis du klikker på Gem øverst til højre på skærmen og sender lige efter det, sendes din anmodning. Testscriptet udføres derefter for at afgøre, om svaret havde status 200 eller ej.

typer af test

der er tre forskellige typer tests. Ved at forstå dem kan du vælge den rigtige type test for de forskellige dele af din programstabel.

enhedstest

enhedstest er den enkleste type test. De kontrollerer rigtigheden af små dele af din kode. En enhedstest dækker normalt et opkald til en funktion eller en måde at bruge en klasse på.

en enhedstest er normalt den første” bruger ” af din kode. Nogle testmetoder kræver endda, at du skriver testen inden implementeringen af den faktiske applikationskode.

Unit tests kan bruges i både backend og frontend udvikling. Nogle udviklingshold bruger enhedstest til at kontrollere den gengivne DOM-output af små dele af deres kode, som formularer eller menuer. I backend bruges enhedstest ofte til at teste koden mellem HTTP-serveren og databasen eller andre API ‘ er.

tre udbredte testløbere til enhedstest er:

‐ Jest—Jest bruges mest i frontend-udvikling, fordi den leveres med unikke funktioner, som snapshot-test, som hjælper med problemer som UI-regressioner. En sjov tutorial kan findes her.

‐ AVA—AVA er begunstiget i backend udvikling, fordi det har specialiseret sig i meget parallel udførelse af tests. En AVA tutorial kan findes her.

‐ PHPUnit—PHPUnit er en populær ramme for enhedstest i PHP. En PHPUnit tutorial kan findes her.

hvis en enhedstest kræver nogle eksterne ressourcer, som netværksforbindelser eller databaser, skriver du sandsynligvis en integrationstest. Denne type test er dækket næste.

integrationstest

fra et implementeringsperspektiv ser integrationstest ud som enhedstest. Forskellen er, at integrationstest tester flere dele af stakken sammen. For eksempel kan de teste, om klienten og serveren taler den samme protokol eller, i en microservices-arkitektur, om tjenesterne fungerer korrekt sammen eller ej.

kontroller, der normalt ville ende i flere uafhængige enhedstest, kan aggregeres i en integrationstest, der bestemmer, om alt fungerer godt sammen.

integrationstest anvendes i både frontend og backend udvikling. De bruges undertiden til at se, om de to dele interagerer korrekt, men de kan også bruges til at bestemme, om forskellige moduler på en del arbejder sammen efter hensigten.

du kan bruge de samme testløbere til integrationstest, som du brugte til enhedstest. Postman, UI-værktøjet, der bruges ovenfor til at automatisere manuelle API-test, leveres dog også med et CLI-værktøj kaldet Nyman, der kan integreres med din CI/CD-pipeline.

Nymand kan køre eksporterede Postbudssamlinger, så du kan oprette anmodninger og tests med postbudets brugergrænseflade og køre dem senere via CLI. En ny tutorial kan findes her.

hvis en integrationstest kræver interaktion med brugergrænsefladen, kaldes den en UI—test-adresseret næste.

UI-test

UI-test er de mest sofistikerede tests. De forsøger at efterligne brugeradfærd på en automatiseret måde, så testere ikke behøver at klikke gennem alle dele af deres app manuelt.

UI-test hjælper ofte med at fange en bestemt interaktion, der førte til en fejl for en bruger. Når den er fanget, kan den gengives med et enkelt klik for at rette fejlen og forhindre den i at komme tilbage i en ny version.

de Jest-og AVA-testløbere, der er nævnt før, kan bruges her, men du har normalt brug for et ekstra bibliotek for at lette UI-interaktionen via en bro.ser. De to hovedbiblioteker, der i øjeblikket bruges til denne proces, er:

‐ Puppeteer—Puppeteer er et JavaScript-bibliotek, der leveres med en hovedløs implementering af Chrome, der gør det muligt at køre UI-tests programmatisk i baggrunden. En Puppeteer tutorial kan findes her.

‐ selen—selen er en ramme, der tillader fjernbetjening af en bro.ser via et bibliotek kaldet Netdriver. En selen tutorial kan findes her.

der er flere typer tests end dem, der er anført her. Andre kan have forskellige mål; for eksempel forsøger belastningstest at finde præstationsflaskehalse. Husk, at de her beskrevne tests undertiden får forskellige navne. De tre typer, der præsenteres ovenfor, er de væsentlige, der skal implementeres, når man kommer i gang. Brug af en af dem er bedre end at bruge ingen automatiseret test overhovedet.

testmetoder

testmetoder er måder at tænke på test. De tre beskrevet nedenfor er de mest almindeligt anvendte.

Test Driven Development (TDD)

TDD er den mest anvendte metode og den mest tekniske. Det anbefaler, at du skriver dine tests, før du skriver den faktiske kode, du vil teste. Da du kun skal skrive en test for den del af koden, du implementerer, er den type test, du vil skrive, en enhedstest.

enhedstest er ret granulære, så over tid resulterer brugen af denne metode i akkumulering af mange tests. Denne virkelighed, parret med det faktum, at begyndere TDD-udøvere har tendens til at skrive trivielle tests, kan føre til oprettelsen af en bunke ubrugelige tests. For at undgå dette er det afgørende at opdatere og rydde op i test, når holdet er blevet mere fortrolig med TDD og med test generelt.

det er vigtigt at køre testene ofte, ikke kun i en CI/CD-pipeline, men også lokalt på din udviklingsmaskine. Skriv en test, køre det, se det mislykkes, gennemføre nok til at gøre testen pass, og gentag processen.

for yderligere læsning, tjek Agile Alliances beskrivelse af TDD.

Acceptance Test Driven Development (Atdd)

ATDD er en ændring af TDD, der fokuserer mere på forretningssager og mindre på teknisk implementering. De testtyper, der bruges i denne metode, er for det meste integrationstest, fordi flere dele af systemet ofte skal bruges sammen for at løse et forretningsbehov.

da testene er mindre tekniske, anbefales det også at inkludere ikke-teknisk orienterede personer i testprocessen. Produkt ejere og kunder kan hjælpe med at definere business cases, så en udvikler kan skrive en test for dem. Hvis testen ikke kan køres med succes, er det klart, at mere funktionalitet skal implementeres.

ATDD arbejder på et andet abstraktionsniveau end TDD, så de to metoder kan bruges sammen.

for yderligere læsning, tjek Agile Alliances beskrivelse af TDD.

Behavior Driven Development (BDD)

BDD er en blanding af TDD og ATDD, og dens mål er at bruge det bedste fra begge verdener til at gøre det samlede system mere stabilt. BDD forsøger at specificere et system med test, der illustrerer dets brug.

ligesom ATDD forsøger BDD at fange forretningssager. Det kræver dog også, at du stiller spørgsmålstegn ved disse brugssager med “5 Hvorfor”, fordi “hvorfor” er en manglende del i ATDD. Sikker på, det er bedre at spørge kunderne, hvad de vil have i stedet for kun at stole på udviklerinput. Men det er også vigtigt at sætte spørgsmålstegn ved antagelserne fra begge disse grupper.

BDD er også en blanding af TDD og ATDD i betydningen abstraktionsniveauer. TDD tester kun de små dele af din applikation, og ATDD tester kun, hvordan disse dele fungerer sammen. BDD kræver, at du anvender denne metode til den store helhed af din app og dens små dele, hvilket gør BDD til en mere holistisk tilgang til test.

for yderligere læsning, tjek Agile Alliances beskrivelse af BDD.

konklusion

selvom ingen test er forfærdelig, er manuel test bedre, og automatiseret test er den bedste.

afhængig af størrelsen på din app kan en manuel test blokere medlemmer af udviklingsholdet fra at arbejde på andre projekter i dage eller endda uger, hvilket koster din virksomhed tid og penge. Derudover kan den monotone opgave med at udføre de samme interaktioner igen og igen føre til glider, der ofte manifesterer sig i ikke-fangede bugs.

computere er meget gode til at gentage den samme opgave igen og igen, så det er en god ide at delegere test til et script og frigøre dine udvikleres tid. Hvis disse tests er integreret i din CI/CD-pipeline, kan de allerede skriftlige tests bare køre implicit, når en ny commit lander i dine arkiver.

det er en god ide at anvende en testmetode tidligt, fordi de store problemer, når man kommer i gang, ofte er “hvad” og “hvornår” at teste. Disse metoder kan hjælpe med at afklare en proces, der gør skrivetest mere konsistente for alle medlemmer af teamet.