Hva er end-to-end (E2E) testing?

Question

Accepted Answer

**End-to-end (E2E) testing** verifiserer **hele applikasjonen fra brukerens perspektiv** — testing av komplette arbeidsflyter gjennom det reelle systemet (UI, backend, database) slik en bruker ville oppleve dem. Det gir høyest tillit til at hele systemet fungerer, men er langsommere og mer skjør.

## Hva E2E testing gjør

```text
E2E tests verify COMPLETE user flows through the WHOLE system:
  → simulate a real USER: open the app, click/type, navigate, submit, verify results
  → exercise the FULL stack: UI → backend → database → and back (everything integrated)
  → e.g. "user logs in, adds an item to the cart, checks out, sees confirmation"
→ tests the app as users actually experience it.
```

## Eksempel (web, med Playwright/Cypress)

```js
test('user can log in and see dashboard', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'user@example.com');
  await page.fill('#password', 'password');
  await page.click('button[type=submit]');         // act like a user
  await expect(page.locator('h1')).toHaveText('Dashboard');  // verify the outcome
});
```

E2E-verktøy (Playwright, Cypress, Selenium for web; Detox, Appium for mobil) styrer det reelle grensesnittet som en bruker ville gjøre.

## Avveiinger (toppen av pyramiden)

```text
✓ HIGHEST CONFIDENCE — verifies the WHOLE system works together, as users see it
✗ SLOW (real browser/app, full stack); BRITTLE (UI changes, timing → FLAKY tests);
  EXPENSIVE to write/maintain; harder to debug failures
→ Have FEW E2E tests — cover CRITICAL user flows only (login, checkout, core paths);
  rely on unit/integration tests for the rest.
```

## Hvorfor det betyr noe

Å forstå end-to-end testing er verdifullt fordi det gir **høyest tillit til at hele systemet fungerer** slik brukere opplever det, samtidig som det har viktige avveiinger som påvirker hvordan det bør brukes, så det er viktig testkunnskap.

E2E-tester verifiserer **komplette brukerflyter gjennom hele det integrerte systemet** (UI, backend, database) ved å simulere reelle brukerhandlinger — og gir den unike verdien å bekrefte at hele applikasjonen faktisk fungerer sammen fra brukerens perspektiv (noe enhetstester og integrasjonstester, som tester deler, ikke fullt ut kan gi).

Dette gjør E2E-tester verdifulle for å verifisere kritisk end-to-end-funksjonalitet.

Men å forstå **avveiingene** er like viktig: E2E-tester er **langsomme** (kjører den reelle nettleseren/appen og hele stacken), **skjøre** (følsomme for UI-endringer og timing, noe som gjør dem utsatt for ustabilitet — et reelt, frustrerende problem), dyre å skrive og vedlikeholde, og vanskeligere å feilsøke.

Disse avveiingene er hvorfor E2E-tester ligger på **toppen av testpyramiden med færrest tester** — de bør kun dekke **kritiske brukerflyter** (pålogging, kjøp, kjernestier) mens enhetstester og integrasjonstester håndterer resten.

Å forstå dette — E2E's høye tillit men høye kostnad, og den resulterende veiledningen om å bruke dem sparsomt for kritiske flyter — er den sentrale praktiske innsikten som forhindrer den vanlige feilen å være for avhengig av langsomme, skjøre E2E-tester.

Å kjenne verktøyene (Playwright, Cypress, Selenium, Detox, Appium) gir praktisk kontekst.

Siden E2E testing gir unik, høy tillit til at hele systemet fungerer (verdifullt for kritiske flyter) men har betydelige avveiinger (langsomt, skjørt, dyrt) som tilsier å bruke det nøye, og siden å forstå både dets verdi og dets riktige, begrenset rolle er viktig for god teststrategi, er forståelse av end-to-end testing verdifull, praktisk relevant kunnskap — viktig for å verifisere at kritiske brukerflyter fungerer end-to-end mens du forstår avveiingene som betyr at det bør brukes sparsomt, en nøkkeldel av en balansert testtilnærming.