Wat is end-to-end (E2E) testing?

Question

Accepted Answer

**End-to-end (E2E) testing** verifieert de **volledige applicatie vanuit het perspectief van de gebruiker** — het testen van complete workflows via het echte systeem (UI, backend, database) zoals een gebruiker deze zou ervaren. Het biedt het hoogste vertrouwen dat het hele systeem werkt, maar is langzamer en brozer.

## Wat E2E testing doet

```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.
```

## Voorbeeld (web, met 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 tools (Playwright, Cypress, Selenium voor web; Detox, Appium voor mobiel) besturen de echte UI zoals een gebruiker.

## Trade-offs (de top van de piramide)

```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.
```

## Waarom het belangrijk is

End-to-end testing begrijpen is waardevol omdat het **het hoogste vertrouwen biedt dat het volledige systeem werkt** zoals gebruikers het ervaren, terwijl het belangrijke trade-offs heeft die bepalen hoe het moet worden gebruikt. Het is daarom belangrijk testingkennis.

E2E tests verifiëren **volledige gebruikersflows via het geheel geïntegreerde systeem** (UI, backend, database) door echte gebruikersacties te simuleren — dit biedt de unieke waarde van het bevestigen dat de gehele applicatie daadwerkelijk samenwerkt vanuit het perspectief van de gebruiker (iets wat unit- en integratietests, die delen testen, niet volledig kunnen bieden).

Dit maakt E2E tests waardevol voor het verifiëren van kritieke end-to-end functionaliteit.

Het begrijpen van de **trade-offs** is echter even belangrijk: E2E tests zijn **traag** (het echte browser/app en complete stack uitvoeren), **broos** (gevoelig voor UI-veranderingen en timing, wat ze gevoelig maakt voor flakiness — een echt, frustrerend probleem), duur om te schrijven en onderhouden, en moeilijker om te debuggen.

Deze trade-offs zijn waarom E2E tests aan **de top van de testpiramide zitten met de minste tests** — ze moeten alleen **kritieke gebruikersflows** (login, checkout, kernpaden) dekken terwijl unit- en integratietests de rest afhandelen.

Dit begrijpen — E2E's hoog vertrouwen maar hoge kosten, en de resulterende richtlijnen om ze voorzichtig in te zetten voor kritieke flows — is het sleutelprobleem dat de veel voorkomende fout van te veel vertrouwen op trage, broze E2E tests voorkomt.

De tools kennen (Playwright, Cypress, Selenium, Detox, Appium) biedt praktische context.

Omdat E2E testing uniek hoog vertrouwen biedt dat het hele systeem werkt (waardevol voor kritieke flows) maar significante trade-offs heeft (traag, broos, duur) die bepalen dat het voorzichtig moet worden gebruikt, en omdat het begrijpen van zowel de waarde ervan als de juiste beperkte rol ervan belangrijk is voor gezonde teststrategie, is het begrijpen van end-to-end testing waardevol, praktisch relevant kennis — belangrijk voor het verifiëren dat kritieke gebruikersflows end-to-end werken terwijl je begrijpt dat de trade-offs betekenen dat het spaarzaam moet worden gebruikt, een belangrijk onderdeel van een evenwichtige testaanpak.