Slik Tester Du Webappene Dine

i programvareindustrien tester alle sine applikasjoner på en eller annen måte. Mange utviklerteam har forseggjorte testordninger som er godt integrert med deres kontinuerlige integrasjonsrørledninger, men selv de som ikke har automatiske tester, må fortsatt finne måter å kontrollere at koden deres fungerer som beregnet.

Å Bygge et nettsted og klikke gjennom det manuelt ved hjelp av en nettleser er en rekke tester. Selv om det ikke er den mest sofistikerte, teller det fortsatt. Det samme gjelder for å skyte opp cURL i konsollen og sende en syntetisk forespørsel TIL API-endepunktet du nettopp opprettet.

dette innlegget vil diskutere hvordan man automatiserer den manuelle testingen vi allerede gjør før du dykker inn i forskjellige testtyper og metoder.

Automatiseringstester

Manuelle tester er tilstrekkelige for små apper, men Når disse appene vokser, vokser deres testbare overflate med dem, noe som forårsaker to problemer.

En, når folk må utføre tester hver gang en ny versjon av en app er ferdig, kan det oppstå uoverensstemmelser. Dette gjelder spesielt hvis det er mange tester. To, personen som gjør testene, kan ikke utføre andre oppgaver. Med store apper kan testing ta flere dager.

den mest logiske måten å løse disse to problemene på er å automatisere disse manuelle oppgavene. Det finnes to hovedtyper av tester for web apps: UI-tester og API-tester. To verktøy kan automatisere dem.

UI Tester

UI tester kan utføres med et verktøy kalt Puppeteer. Puppeteer lar deg automatisere en manuell UI test ved Hjelp Av JavaScript. Den er installert via NPM med følgende kommando:

 $ npm i puppeteer

du kan deretter skrive et skript som styrer en hodeløs Versjon Av Chrome for å kjøre testene dine. Dette skriptet kan se ut 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 skriptet starter vi en hodeløs forekomst Av Chrome, navigerer til example.com, og leter etter et h1-element. Hvis den ikke finnes, logges en feilmelding.

API-Tester

API-tester kan automatiseres Via Postbud. Postman kommer med et grafisk grensesnitt for å bygge HTTP-forespørsler som kan lagres. Disse forespørslene kan utføres senere med bare et museklikk.

last Ned Og installer Postman UI for å komme I gang. Følgende trinn er nødvendig for å opprette og lagre en forespørsel:

  1. Klikk På Opprett En Samling til venstre
  2. Skriv Inn Min Samling Som samlingsnavn
  3. Klikk På Opprett
  4. Klikk på ellipsen (…) I Min Samling til venstre
  5. Velg Legg Til Forespørsel
  6. Skriv Inn Min Forespørsel som forespørselsnavn
  7. Klikk På Lagre I Min Samling

forespørselen vises i venstre sidefelt under Den Nyopprettede samlingen.

hvis du velger det, må du skrive inn example.com SOM EN URL og legge til en test. For å legge til en test, klikk På Tester i fanelinjen under URL-inntastingsfeltet.

et tekstområde der du kan skrive testen din 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 Lagre øverst til høyre på skjermen Og Sende rett etter det, vil forespørselen bli sendt. Testskriptet vil da utføre for å avgjøre om svaret hadde status 200 eller ikke.

Typer Tester

det finnes tre forskjellige typer tester. Ved å forstå dem kan du velge riktig type testing for de ulike delene av programvarestakken din.

Enhetstester

Enhetstester er den enkleste typen test. De kontrollerer korrektheten av små deler av koden din. En enhet test dekker vanligvis en samtale til en funksjon eller en måte å bruke en klasse.

en enhetstest er vanligvis den første “brukeren” av koden din. Noen testmetoder krever selv at du skriver testen før implementeringen av den faktiske applikasjonskoden.

Enhet tester kan brukes i både backend og frontend utvikling. Noen utviklingsteam bruker enhetstester for å kontrollere GJENGITTE DOM-utdata av små deler av koden, som skjemaer eller menyer. I backend brukes enhetstester ofte til å teste koden mellom HTTP-serveren og databasen eller andre Apier.

Tre mye brukt test løpere for enhet tester er:

—Jest-Jest er mest brukt i frontend utvikling fordi den kommer med unike funksjoner, som snapshot testing, som hjelper med problemer som UI regresjoner. En Spøk tutorial kan bli funnet her.

—AVA-ava er foretrukket i backend utvikling fordi den spesialiserer seg på svært parallell utførelse av tester. En ava tutorial kan bli funnet her.

‐ PHPUnit-PHPUnit er et populært rammeverk for enhet tester I PHP. En PHPUnit tutorial kan bli funnet her.

hvis en enhetstest krever noen eksterne ressurser, som nettverkstilkoblinger eller databaser, skriver du sannsynligvis en integrasjonstest. Denne typen test er dekket neste.

Integrasjonstester

fra et implementeringsperspektiv ser integrasjonstester ut som enhetstester. Forskjellen er at integrasjonstester tester flere deler av stakken sammen. For eksempel kan de teste om klienten og serveren snakker samme protokoll eller, i en mikrotjenestearkitektur, om tjenestene fungerer riktig sammen.

Kontroller som vanligvis vil ende opp i flere uavhengige enhetstester, kan aggregeres til en integrasjonstest som bestemmer om alt fungerer godt sammen.

Integrasjonstester brukes i både frontend og backend utvikling. De brukes noen ganger til å se om de to delene samhandler riktig, men de kan også brukes til å avgjøre om forskjellige moduler av en del jobber sammen som beregnet.

du kan bruke de samme testløperne for integrasjonstester som du brukte for enhetstester. Men Postman, UI-verktøyet som brukes ovenfor for å automatisere manuelle API-tester, kommer også med Et Cli-verktøy kalt Newman som kan integreres med CI/CD-rørledningen.

Newman kan kjøre eksporterte Postmann samlinger, slik at du kan lage forespørsler og tester Med Postmann UI og kjøre dem senere via CLI. En Newman tutorial kan bli funnet her.

hvis en integrasjonstest krever interaksjon med BRUKERGRENSESNITTET, kalles det EN UI—test-adressert neste.

UI Tester

UI tester er de mest sofistikerte tester. De prøver å etterligne brukeradferd på en automatisert måte, slik at testere ikke trenger å klikke gjennom alle deler av appen manuelt.

UI-tester bidrar ofte til å fange opp en bestemt interaksjon som førte til en feil for en bruker. Når den er fanget, kan den reproduseres med ett klikk for å fikse feilen og forhindre at den kommer tilbake i en ny versjon.

Jest og ava test løpere nevnt før kan brukes her, men du trenger vanligvis et ekstra bibliotek for å lette BRUKERGRENSESNITTET via en nettleser. De to hovedbibliotekene som er i bruk for denne prosessen er:

‐ Puppeteer-Puppeteer er Et JavaScript-bibliotek som kommer med en hodeløs implementering Av Chrome som gjør det mulig å kjøre UI-tester programmatisk i bakgrunnen. En Puppeteer tutorial kan bli funnet her.

‐ Selen—Selen er et rammeverk som tillater fjernkontroll av en nettleser via et bibliotek kalt WebDriver. En Selenopplæring finner du her.

det finnes flere typer tester enn de som er oppført her. Andre kan ha forskjellige mål, for eksempel prøver belastningstester å finne flaskehalser for ytelse. Husk at testene beskrevet her er noen ganger gitt forskjellige navn. De tre typene som presenteres ovenfor er de viktigste å implementere når du kommer i gang. Å bruke en av dem er bedre enn å bruke ingen automatisert testing i det hele tatt.

Testmetoder

Testmetoder er måter å tenke på testing. De tre som er beskrevet nedenfor, er de mest brukte.

Testdrevet Utvikling (Tdd)

TDD er den mest brukte metodikken og den mest tekniske. Det anbefaler at du skriver testene dine før du skriver den faktiske koden du vil teste. Siden du må skrive en test for bare den delen av koden du implementerer, er typen test du vil skrive en enhetstest.

Enhetstester er ganske granulære, så over tid resulterer bruk av denne metoden i akkumulering av mange tester. Denne virkeligheten, sammen med det faktum at nybegynnere tdd-utøvere pleier å skrive trivielle tester, kan føre til opprettelse av en haug med ubrukelige tester. For å unngå dette er det viktig å oppdatere og rydde opp tester når teamet har blitt mer kjent MED TDD og med testing generelt.

det er viktig å kjøre testene ofte, ikke bare i EN CI/CD-rørledning, men også lokalt på utviklingsmaskinen din. Skriv en test, kjør den, se den mislykkes, implementer nok til å gjøre testen bestått, og gjenta prosessen.

for videre lesing, sjekk Ut Agile Alliances beskrivelse AV TDD.

Acceptance Test Driven Development (Atdd)

ATDD er en modifikasjon AV TDD som fokuserer mer på forretningssaker og mindre på teknisk implementering. Testtypene som brukes i denne metoden er for det meste integrasjonstester, fordi ofte flere deler av systemet må brukes sammen for å løse et forretningsbehov.

siden testene er mindre tekniske, er det også tilrådelig å inkludere ikke-teknisk orienterte personer i testprosessen. Vare eiere og kunder kan bidra til a definere forretningssaker slik at en utvikler kan skrive en test for dem. Hvis testen ikke kan kjøres, er det klart at mer funksjonalitet må implementeres.

ATDD fungerer på et annet abstraksjonsnivå ENN TDD, slik at de to metodene kan brukes sammen.

for videre lesing, sjekk Ut Agile Alliances beskrivelse AV TDD.

Behavior Driven Development (Bdd)

BDD er en blanding AV TDD og ATDD, og målet er å bruke det beste fra begge verdener for å gjøre systemet mer stabilt. BDD prøver å spesifisere et system med tester som illustrerer bruken.

som ATDD prøver BDD å fange forretningssaker. Det krever imidlertid også at du stiller spørsmål ved disse brukssakene med” 5 whys “fordi ” whys” er en manglende del i ATDD. Jo, det er bedre å spørre kundene hva de vil, i stedet for å stole utelukkende på utviklerinngang. Men det er også viktig å stille spørsmål ved antagelsene til begge disse gruppene.

BDD er også en blanding AV TDD og ATDD i betydningen av abstraksjonsnivåer. TDD tester bare de små delene av søknaden din og ATDD tester bare hvordan disse delene fungerer sammen. BDD krever at du bruker denne metoden til den store hele appen din og dens små deler, noe SOM gjør BDD til en mer helhetlig tilnærming til testing.

for videre lesing, sjekk Ut Agile Alliances beskrivelse AV BDD.

Konklusjon

selv om ingen testing er forferdelig, er manuell testing bedre, og automatisert testing er best.

avhengig av størrelsen på appen din, kan en manuell test blokkere medlemmer av utviklingsteamet fra å jobbe med andre prosjekter i dager eller uker, noe som koster bedriften din tid og penger. I tillegg kan den monotone oppgaven med å utføre de samme interaksjonene igjen og igjen føre til slips som ofte manifesterer seg i uoppfangede feil.

Datamaskiner er veldig gode til å gjenta den samme oppgaven igjen og igjen, så det er en god ide å delegere testing til et skript og frigjøre utviklerens tid. Hvis disse testene er integrert i CI / CD-rørledningen, kan de allerede skrevne testene bare kjøre implisitt når en ny commit lander i depotene dine.

det er en god ide å bruke en testmetodikk tidlig, fordi de store problemene når du kommer i gang, ofte er” hva “og” når ” å teste. Disse metodene kan bidra til å klargjøre en prosess som gjør skrivetester mer konsistente for alle medlemmer av teamet.

Leave a Reply