Hva er testing? Hvorfor er det viktig? Hva skal vi teste? Hvordan skal vi teste?
Testing er et veldig stort emne og det er mye som vi ikke kommer til å komme inn på her. Brukertesting, akseptansetesting, ytelsestesting, stresstesting, osv. Vi skal se på testing av kode og de verktøyene og prosessene som er aktuelle for oss.
Det finnes mye fin og fancy teori rundt testing, på samme måte som det finnes tilsvarende for utvikling og prosjektgjennomføring osv. Men en ting de fleste ser ut til å være enige om er at jo tidligere man tester og fanger opp feil og mangler, jo enklere og billigere er det å rette opp. Det kalles ofte "shift-left" testing.
Testing er viktig for å sikre at vi leverer kvalitet. Hvis vi ikke har gode tester så vil vi bruke mer tid på å teste manuelt og vi vil være redde for å gjøre endringer fordi vi ikke vet om det vil ødelegge noe annet. Med gode og dekkende tester kan vi gjøre endringer med god samvittighet og vi kan levere nye versjoner oftere og raskere fordi vi vet at vi ikke har ødelagt noe. For å få automatisert testingen mest mulig prøver vi å få den inn som en del av bygge- og leveranseprosessen.
En av de mest grunnleggende test metodikkene for kode kalles enhetstesting. Det innebærer å teste hver enkelt enhet/funksjon for seg. Ved å ha gode tester på denne nivået kan vi være sikre på at hver enkelt funksjon fungerer som den skal. Det gjør det også enklere å finne feil og mangler fordi vi vet at feilen må være i den funksjonen vi tester. Det er også enklere å skrive tester fordi vi ikke trenger å tenke på hvordan funksjonen blir brukt i resten av applikasjonen. Vi kan bare teste den ene funksjonen og ikke tenke på resten av applikasjonen. Dersom vi senere endrer funksjonen og skaper en feil så bør testen feile og fange opp problemet.
For JavaScript og TypeScript finnes det mange forskjellige verktøy for enhetstesting. Det mest populære er Jest. Under ser du et eksempel på en test skrevet med Jest. Dette er et veldig forenklet og litt oppkonstruert eksempel hvor vi har en funksjon som sjekker om svaret på en oppgave er like fasiten. Testen sjekker da både at funksjonen gir et positivt resultat når svaret er riktig og at den gir et negativt resultat når svaret er feil.
Jest kan også brukes for det som kalles snapshot testing, for å sikre at vi ikke utilsiktet endrer på ting. Det kan f.eks være at vi utilsiktet endrer på en tekst eller en klasse på en komponent. Da vil snapshot testingen feile og vi må gå inn og se på hva som har endret seg og om det er en utilsiktet endring eller om det er en endring vi ønsker.
Ved å bruke et verktøy som heter axe kan vi også teste for universell utforming i enhetstestene. axe er utviklet av Deque og kan integreres i mange andre verktøy. Det kan f.eks brukes både i Jest og Cypress så vi kan da fange opp en del problemer så tidlig som mulig.
For å gjøre bruken av Jest ennå bedre og enklere for testing av UI bruker vi også Testing Library.
Jest har vært ganske enerådene lenge men nå har det kommet ihvertfall en ganske sterk konkurrent som heter Vitest og er basert på Vite.
Storybook er et godt verktøy for å teste komponenter helt isolert fra resten av applikasjonen. Det er også et godt verktøy for å dokumentere komponenter.
Det finnes også en del forskjellige addons til Storybook som kan være nyttige. F.eks et for UU testing. Figma kan også integreres med Storybook for å enklere sikre at vi implementerer det designet vi skal ha.
Og vi kan bruke Chromatic for å teste komponentene for visuelle endringer så vi bare får med de endringene vi ønsker og ikke utilsiktede endringer.
Jest kan også brukes for å teste komponenter. Men Storybook er stort sett bedre egnet. Både Jest og Storybook kan også brukes for å teste komponenter sammen med andre komponenter. Det er da en form for integrasjonstesting. For enkelte typer prosjekter kan integrasjonstesting mer eller mindre erstatte enhetstesting og være enklere å vedlikeholde.
I e2e testing ønsker vi å automatisere det som en bruker ville gjort. Vi ønsker å teste at applikasjonen fungerer som den skal og at den ser ut som den skal. Vi ønsker også å teste at applikasjonen fungerer på forskjellige enheter og nettlesere.
Cypress er et av de vektøyene vi bruker for dette. Den kjører da tester med en reell nettleser og klikker rundt i appen/nettsiden omtrent som en vanlig bruker. Vi kan også kjøre Cypress i "headless" modus fra terminalen og kan da brukes i CI/CD prosessen (GitHub Actions).
For å teste med Cypress på et ennå større utvalg av nettlesere enn de vi selv har installert på egen maskin kan vi også kjøre Cypress på Browserstack for å dekke ennå flere.
Også i Cypress kan vi legge inn axe og kan da fange opp problemer som ikke var mulig å fange opp i enhetstestene.
Både Jest og Cypress er egentlig litt "blinde", de ser ikke utseende på nettsiden (CSS), de ser bare html-koden (DOM) så de kan ikke fange opp ting som at en boks har fått feil farge eller størrelse.
Percy er et slikt verktøy som kan fange opp visuelle endringer. Det kan integreres med Storybook og det kan integreres med GitHub så hver gang vi pusher ny kode blir det testet og sjekket før endringene blir godkjent og lagt inn i koden. Percy har blitt kjøpt opp av Browserstack så det er tett integrert med Browserstack.
Chromatic er et annet verktøy for visuell testing. Det kan tett integreres med Storybook siden det er laget av de samme personene. Og både Storybook og Chromatic kan integreres med Figma for å sikre at vi implementerer det designet vi skal ha.
UU testing må ikke være noe som utsettes til slutt, da blir det for vanskelig og dyrt å rette opp ting. Det må være integrert i alle andre deler av testingen.
For automatisert testing er axe ofte grunnkomponenten for UU testing både i Jest, Storybook og Cypress. Men det kan også installeres som et tillegg i nettleseren for testing av publiserte nettsider.
I tillegg finnes det en god del andre verktøy som vi kan bruke:
Men disse automatiske verktøyene klarer ikke teste alt så det må også gjøres en del manuell testing. F.eks teste at all interaktivitet kan brukes med tastatur og at alt fungerer som det skal med skjermleser. De skjermleserne vi bør teste med er: JAWS, NVDA, VoiceOver (på iOS og macOS) og TalkBack (på Android)
OWASP - Open Worldwide Application Security Project De er mest kjent for sin årlige topp 10 liste med sikkerhetsrisikoer men de har også både verktøy og guider for sikkerhetstesting. OWASP Web Security Testing Guide er en steg for steg liste med prosedyrer for å teste sikkerhet.
Snyk har også en rekke ulike verktøy og tjenester for sikkerhetstesting. Det kan integreres med GitHub for å teste kode hver gang vi lagrer ny kode. Det kan brukes som CLI for å teste kode lokalt. Og det kan integreres direkte i kodeeditoren (f.eks VS Code) for å fange opp sikkerhetsproblemer mens vi skriver koden.
I tillegg til de automatiserte testene bruker vi også en god del tid på manuell testing. Det meste av det vi leverer skal fungere på både pc, mac, nettbrett og mobil. Og det skal fungere i de vanligste nettleserne, og som regel i de to nyeste versjonene av operativsystem og nettleser. Det kan fort bli veldig tidkrevende så vi prøver å automatisere så mye som mulig. Og automatiseringne er gjerne et resultat av å ha gått gjennom en sjekkliste manuelt noen ganger til man ser at dette lønner seg å automatisere.
--
Som nevnt i starten er testing mye mer enn det vi har fått med over her. Vi må teste både kursinnhold vi produserer, nettsider for LMS'et, administrasjonssider for LMS'et og selve REST API'et, server-siden av LMS'et. For serveren er mange av de samme typene tester aktuelt men det er også en del andre typer tester som er mer aktuelle for serveren. F.eks ytelsestesting, sikkerhetstesting, osv.