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

Question

Accepted Answer

**End-to-end (E2E) testing** verificerer det **komplette program fra brugerens perspektiv** — ved at teste komplette arbejdsgange gennem det rigtige system (UI, backend, database) som en bruger ville opleve det. Det giver det højeste niveau af sikkerhed for, at hele systemet fungerer, men er langsommere og mere skrøbeligt.

## Hvad E2E testing gø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-værktøjer (Playwright, Cypress, Selenium til web; Detox, Appium til mobile) styrer det rigtige UI som en bruger ville gøre.

## Trade-offs (toppen af 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 betyder noget

At forstå end-to-end testing er værdifuldt, fordi det giver det **højeste niveau af sikkerhed for, at det komplette system fungerer** som brugerne oplever det, mens det har vigtige trade-offs, der påvirker hvordan det bør bruges, så det er vigtig testningsviden.

E2E-tests verificerer **komplette brugerflow gennem hele det integrerede system** (UI, backend, database) ved at simulere rigtige brugerhandlinger — hvilket giver den unikke værdi at bekræfte, at hele programmet faktisk fungerer sammen fra brugerens perspektiv (noget som unit- og integrationstests, der tester dele, ikke fuldt ud kan give).

Dette gør E2E-tests værdifulde for at verificere kritiske end-to-end-funktionalitet.

Men forståelsen af **trade-offs** er lige så vigtig: E2E-tests er **langsomme** (de kører den rigtige browser/app og hele stacken), **skrøbelige** (følsomme over for UI-ændringer og timing, hvilket gør dem tilbøjelige til ustabilitet — et virkeligt, frustrerende problem), dyre at skrive og vedligeholde, og sværere at fejlfinde.

Disse trade-offs er grunden til, at E2E-tests sidder **øverst på testpyramiden med færrest tests** — de bør kun dække **kritiske brugerflow** (login, checkout, kernesti) mens unit- og integrationstests håndterer resten.

At forstå dette — E2E's høje sikkerhed men høje omkostning, og den resulterende vejledning om at bruge dem sparsomt til kritiske flow — er det vigtigste praktiske indsigt, der forhindrer den almindelige fejl at være for afhængig af langsomme, skrøbelige E2E-tests.

At kende værktøjerne (Playwright, Cypress, Selenium, Detox, Appium) giver praktisk kontekst.

Fordi E2E-testing giver unik, høj sikkerhed for, at hele systemet fungerer (værdifuldt for kritiske flow) men har betydelige trade-offs (langt, skrøbeligt, dyrt), der dikterer at bruge det med omhu, og fordi forståelsen af både dets værdi og dets rette begrænsede rolle er vigtig for en sund teststrategi, er forståelsen af end-to-end testing værdifuld, praktisk-relevant viden — vigtig for at verificere, at kritiske brugerflow fungerer end-to-end, mens man forstår de trade-offs, der betyder, at det bør bruges sparsomt, en vigtig del af en balanceret testingstilgang.