Hva er programvaretesting? Enhetstester og E2E

01Hva er programvaretesting, og hvorfor trenger man det?

Programvaretesting er måten å bevise at koden du har skrevet faktisk gjør det du vil. At en rabattkode beregnes riktig i en nettbutikk, at to bestillinger ikke kan gjøres på samme rom i en hotellprogramvare, eller at et skjema avviser feil data, sikres med tester.

I prosjekter uten tester medfører hver ny funksjon en risiko for å ødelegge noe som virket før. Dette kalles regresjon. Automatiske tester reduserer denne risikoen. Når noe endres, viser de i løpet av minutter hva som er ødelagt.

Tidspunktet feilen oppdages på avgjør kostnaden. En feil som fanges under utviklingen rettes på noen minutter, mens en feil som kunden finner i produksjon koster penger, tid og tillit.

02Testtyper: enhet, integrasjon, E2E

Testtyper skilles etter hvor stort område de dekker og hvor raskt de kjører. Å teste små deler er raskt og billig, mens å teste hele systemet er tregt, men realistisk.

Hva er en enhetstest?

Enhetstest (unit test) tester én enkelt funksjon eller klasse isolert fra omverdenen. Database, nettverk eller filsystem er ikke med, og om nødvendig etterlignes de med falske objekter (mock). Den kjører på millisekunder og viser nøyaktig hvor feilen er.

Integrasjonstest

Integrasjonstest verifiserer at flere deler fungerer riktig sammen: applikasjon og database, tjeneste og tjeneste, system og et eksternt API. Endepunktene vi beskrev i artikkelen hva er et API testes mest på dette nivået. Disse testene er kritiske i flyter som betaling, frakt og markedsplassintegrasjon.

E2E-test

E2E-test (ende-til-ende-test) bruker systemet som en ekte bruker: åpner nettleseren, legger produktet i handlekurven, går til betalingssteget og kontrollerer at bestillingen er opprettet. Det er den mest realistiske testen, men også den tregeste og mest ømfintlige.

03Testpyramiden: hvor mye av hver test?

Testpyramiden er en utbredt modell for hvor mye som bør skrives av hver testtype. I bunnen er det mange raske enhetstester, i midten færre integrasjonstester og på toppen noen få E2E-tester som bare dekker de kritiske flytene.

Det er en vanlig feil at pyramiden snus opp ned, altså at man prøver å verifisere alt med E2E-tester. Da blir testtiden lang, testene feiler uten grunn, og teamet slutter etter hvert å stole på testene.

Det finnes ikke noe fast forhold. Prosjekttypen avgjør. I programvare med mye beregning veier enhetstestene tungt, mens andelen integrasjonstester øker i et prosjekt som kobles til mange eksterne systemer.

04Eksempel med Jest og Playwright

I JavaScript-verdenen er Jest og Vitest vanlige valg for enhetstester, og Playwright og Cypress for E2E-tester. Under ser du en enkel enhetstest skrevet for en rabattfunksjon.

Hvis du vil fange typefeil før du i det hele tatt skriver tester, kan du også se artikkelen vår hva er TypeScript. Typesystemet lette litt på byrden for testene, men erstatter dem ikke.

// indirim.js
export function indirimUygula(tutar, oran) {
  if (oran < 0 || oran > 100) throw new Error('Ugyldig rate');
  return Math.round(tutar * (100 - oran)) / 100;
}

// indirim.test.js
import { indirimUygula } from './indirim.js';

test('20 prosent rabatt beregnes riktig', () => {
  expect(indirimUygula(200, 20)).toBe(160);
});

test('ugyldig rate gir feil', () => {
  expect(() => indirimUygula(200, 120)).toThrow();
});

import { test, expect } from '@playwright/test';

test('produktet legges i handlekurven', async ({ page }) => {
  await page.goto('https://ornek-magaza.test/urun/zeytinyagi');
  await page.getByRole('button', { name: 'Sepete Ekle' }).click();
  await expect(page.getByTestId('sepet-adet')).toHaveText('1');
});

05Testautomatisering og CI-prosessen

Testautomatisering betyr at testene ikke kjøres for hånd, men automatisk ved hver kodeendring. Når koden sendes til repositoriet, kjører en CI-pipeline (kontinuerlig integrasjon) testene. Hvis en av testene feiler, går ikke endringen i produksjon.

Denne ordningen blir enda mer verdifull når teamet vokser. Alle møter samme kvalitetskrav, og feil fanges før de når kunden.

1. Utvikleren gjør endringen i en gren og sender den til repositoriet.
2. CI-pipelinen installerer avhengighetene og kjører enhets- og integrasjonstestene.
3. E2E-testene for kritiske flyter kjører i testmiljøet.
4. Hvis alle testene går gjennom, settes koden i produksjon etter kodegjennomgang.

06Andre testtyper

Det er ikke nok at programvaren virker riktig. Den må også være rask, sikker og brukervennlig. Derfor finnes det andre testtyper ved siden av de funksjonelle testene.

• Ytelsestest: Måler hvordan systemet oppfører seg under belastning. Sidehastighet er også en del av arbeidet med hastighet og ytelse.
• Sikkerhetstest: Leter etter hull som uautorisert tilgang og injeksjon.
• Brukervennlighetstest: Ser på om ekte brukere kan bruke grensesnittet uten problemer. Det er en naturlig del av prosessen for UI/UX-design.
• Tilgjengelighetstest: Kontrollerer at løsningen passer for brukere av skjermleser og tastatur.
• Visuell regresjonstest: Sammenligner skjermbilder og fanger uventede forskyvninger i designet.
• Tester av kompilerte moduler: Deler som Wasm-modulene vi beskrev i artikkelen hva er WebAssembly trenger også sin egen testpipeline.

07Vanlige feil i testing

Å skrive tester er en ferdighet. Dårlig skrevne tester kan bli en byrde i stedet for en hjelp. Dette er de vanligste feilene.

• Å henge seg opp i dekningsprosent: En høy prosent betyr ikke gode tester. Det viktige er at kritisk oppførsel testes.
• Å teste applikasjonens interne struktur: Når koden refaktoreres, feiler testene uten grunn. Test oppførselen.
• Skjøre E2E-tester: Bruk oppsett som venter på at elementet skal vises, i stedet for faste ventetider.
• Å koble testene til produksjonsdata: Testene bør lage sine egne data og rydde opp etterpå.
• Å skru av en test som feiler og glemme den: Dette ødelegger raskt tilliten til testene.

08Hvor bør du begynne å teste?

Det er ikke realistisk å legge hundrevis av tester inn i et prosjekt uten tester på en gang. Den mer effektive veien er å begynne på det mest risikable stedet og gå gradvis videre. Selv å skrive én test for hver feil som rettes gir et solid sikkerhetsnett i løpet av noen måneder.

I begynnelsen bør målet være pålitelige tester, ikke perfekt dekning. Få tester som gir et konsistent resultat hver gang er mer verdifulle enn mange ustabile tester.

1. List opp funksjonene som har med penger, lager og brukerdata å gjøre.
2. Skriv først enhetstester for disse funksjonene.
3. Legg integrasjonstester til punktene som kobler til eksterne systemer.
4. Sett opp E2E-tester for de to eller tre mest kritiske brukerflytene.
5. Koble testene til CI-pipelinen, og ikke gå i produksjon med en rød test.

09Hva gir tester virksomheten?

For en virksomhetseier er testing en usynlig, men merkbar investering. Derfor er det viktig å teste de kritiske flytene når skreddersydde programvareløsninger utvikles. En betalingsside som krasjer på kampanjedagen eller en butikk som viser feil lagerstatus, blir mye dyrere enn kostnaden for testene.

Når bestillings-, faktura- og lagerflyter går mellom flere systemer, øker sannsynligheten for feil. Å bygge en testet og forutsigbar struktur i prosjekter for integrasjoner for nettbutikker og nettbutikkplattform senker derfor vedlikeholdskostnaden på lang sikt.