Hvilke almindelige testing anti-patterns bør man undgå?

Question

Accepted Answer

Selv med gode intentioner falder teams ind i **testing anti-patterns** — praksisser, der gør tests skrøbelige, langsomme, upålidelige eller lav-værdi. At genkende og undgå dem er vigtigt for at opretholde en sund, værdifuld test suite.

## Test quality anti-patterns

```text
✗ TESTING IMPLEMENTATION DETAILS → tests coupled to internals → break on every refactor
  (brittle) → test BEHAVIOR/outcomes instead
✗ FLAKY tests → intermittent failures erode trust → people ignore failures (real ones too)
✗ OVER-MOCKING → mocking everything → tests verify mock interactions, not real behavior;
  brittle and give false confidence
✗ Tests with NO meaningful assertions → run code but verify nothing (false coverage)
✗ GIANT tests checking many things → unclear what failed; hard to maintain
```

## Structural og strategic anti-patterns

```text
✗ ICE CREAM CONE → mostly slow E2E/manual, few unit tests → slow, brittle, expensive suite
✗ INTERDEPENDENT tests / shared mutable state → order-dependent, flaky, fragile
✗ Testing the FRAMEWORK / trivial code → low value; testing what doesn't need testing
✗ Chasing COVERAGE numbers → low-value tests written just to hit a percentage
✗ Slow tests → discourage running them → defeats fast-feedback value
```

## Process anti-patterns

```text
✗ Writing tests as an afterthought (or never) → poor coverage, untestable design
✗ Ignoring failing/flaky tests → the suite becomes untrusted/useless
✗ Not maintaining tests (test code rot) → tests are code; they need care
→ Recognize these and steer toward: behavior-focused, isolated, fast, meaningful,
  pyramid-shaped, maintained tests.
```

## Hvorfor det betyder noget

At forstå testing anti-patterns er værdifuld seniorniveau-viden, fordi **genkendelse og undgåelse af dårlige testing praksisser er essentiel for at opretholde en sund, værdifuld test suite**, og disse anti-patterns er almindelige selv med gode intentioner, så det er vigtig praktisk viden.

Tests, der falder ind i anti-patterns, bliver en ansvarlighed i stedet for et aktiv, så at vide, hvad man skal undgå, er lige så vigtig som at vide, hvad man skal gøre.

At forstå **test quality anti-patterns** — testing af implementeringsdetaljer (forvolter skrøbelige tests, der går i stykker ved refactoring), **flaky tests** (eroderer tillid, så fejl ignoreres), over-mocking (verifikation af mock-interaktioner i stedet for virkelig adfærd, giver falsk selvtillid), tests uden meningsfulde assertions (falsk coverage), og gigantiske ufokuserede tests — hjælper med at genkende og undgå praksisser, der gør individuelle tests lav-værdi eller kontraproduktive.

At forstå **structural og strategic anti-patterns** — **ice cream cone** (inverteret pyramid: mest langsomme E2E/manuelle tests, producerer en langsom, skrøbelig, dyr suite), afhængige tests, testing af triviel kode eller frameworket, **chasing coverage numbers** (at skrive lav-værdi tests for at ramme et mål), og langsomme tests (som afskrækker fra at køre dem) — hjælper med at undgå en dårligt struktureret, ineffektiv test suite.

At forstå **process anti-patterns** — at skrive tests som en efterimplementering (eller aldrig), **ignorering af failing/flaky tests** (gør suiten upålidelig og ubrugelig), og ikke vedligehold af test kode (lader den rådne) — hjælper med at opretholde en sund testing proces.

At genkende disse anti-patterns og styre mod deres modsætninger (adfærdsfokuseret, isoleret, hurtige, meningsfulde, pyramid-formet, vedligeholdt tests) er det, der holder en test suite værdifuld over tid.

Fordi testing anti-patterns er almindelige (selv med gode intentioner) og de forvandler tests fra et aktiv til en ansvarlighed (skrøbelige, flaky, langsomme, upålidelige, lav-værdi), og fordi genkendelse og undgåelse af dem er essentiel for at opretholde en sund, værdifuld test suite, er forståelse af testing anti-patterns værdifuld senioriveau-viden — vigtig for at holde testing effektiv, reflekterer erfaringen til at genkende og undgå de almindelige fejltagelser, der underminerer test suites, og en nøgle-kompetence for senioringeniører, der vejleder testing praksisser og opretholde test suite sundhed over tid.