Hvordan tester du kode, der interagerer med databaser?

Question

Accepted Answer

Testing af kode, der bruger en **database**, er udfordrende — du skal have realistisk dataadfærd uden flakiness eller langsomhed. Tilgange omfatter **testdatabaser**, **in-memory databaser**, **transaktioner/rollback** og **mocking af datalaget** — hver med fordele og ulemper.

## Udfordringen

```text
Database-interacting code needs testing, but databases bring challenges:
  → real DB → realistic but SLOWER; needs SETUP and CLEANUP (state between tests)
  → shared state → tests can interfere (order dependence, flakiness)
  → mocking the DB → fast but may not catch real query/integration bugs
→ Choose an approach balancing realism, speed, and isolation.
```

## Tilgange

```text
1. REAL TEST DATABASE → a dedicated DB for tests (same engine as production):
   ✓ realistic (catches real query/schema issues)  ✗ slower; needs cleanup/isolation
   → often run in a CONTAINER (Docker) for a clean, consistent DB per test run
2. TRANSACTION ROLLBACK → wrap each test in a transaction, ROLL BACK after → clean state,
   no leftover data, faster than recreating data (a common pattern)
3. IN-MEMORY DATABASE (e.g. SQLite in memory) → fast, easy setup  ✗ may differ from the
   production DB (different SQL/features → can miss prod-specific issues)
4. MOCK the data layer → fast, isolated UNIT tests  ✗ doesn't test real DB behavior
   (use for unit tests; use a real DB for integration tests)
```

## Bedste praksis

```text
✓ ISOLATE tests — each starts from a known clean state (transactions, truncate, fresh DB)
✓ Use realistic test DATA (fixtures/factories/seeds)
✓ Test real DB behavior for the DATA LAYER (integration); mock the DB when unit-testing
  business logic above it
✓ Keep DB tests reasonably fast; run a clean DB in CI (containers)
```

## Hvorfor det betyder noget

At forstå, hvordan man tester kode, der interagerer med databaser, er værdifuldt, fordi **de fleste applikationer bruger databaser**, og at teste dataadgang korrekt er vigtig men udfordrende, så det er nyttig praktisk viden.

Databasekode (queries, dataadgang, persistering) skal testes, men databaser introducerer reelle udfordringer — de er langsommere, kræver opsætning og oprydning, har delt tilstand, der kan forårsage testinterferens og flakiness, og at mocke dem kan misse reelle query-bugs.

At forstå **tilgangene og deres fordele og ulemper** er nøgleviden: en **rigtig testdatabase** (realistisk, opdager faktiske query- og schemabug, kører ofte i en container for konsistens, men langsommere og skal isoleres), **transaction rollback** (indpakke hver test i en transaktion og rulle tilbage for ren tilstand — et almindeligt, effektivt mønster, der holder tests isoleret og rimeligt hurtigt), **in-memory databaser** (hurtige og nemme, men potentielt forskellig fra produktion, risiko for uopdagede produktionsproblemer) og **mocking af datalaget** (hurtige isolerede unit tests, men tester ikke rigtig databaseadfærd).

At forstå, hvornår du bruger hver enkelt — en rigtig database til integration testing af datalaget (for at opdage rigtige query/schema-bugs), mocking til unit testing af forretningslogik over datalaget — afspejler fornuftig vurdering af afvejning mellem realisme, hastighed og isolation.

At forstå **bedste praksis** — **isolering af tests** (hver starter fra en kendt ren tilstand via transaktioner, truncation eller en frisk database, for at undgå interferens og flakiness), brug af realistisk testdata (fixtures/factories), testing af rigtig databaseadfærd for datalaget og kørsel af rene databaser i CI — afspejler effektiv database testing.

Fordi de fleste applikationer bruger databaser, og testing af dataadgang korrekt (opdagelse af query-bugs, samtidig med at tests holdes isoleret, hurtige og pålidelige) er vigtig men udfordrende, og fordi forståelse af tilgangene (rigtig DB, transaktioner, in-memory, mocking), deres fordele og ulemper samt bedste praksis (isolation, realistisk data) muliggør effektiv database testing, er forståelse af, hvordan man tester kode, der interagerer med databaser, værdifuld, praktisk relevant viden — vigtig for det almindelige behov for pålidelig testing af dataadgang, afvejning af realisme mod hastighed og isolation, en nyttig færdighed til testing af datadrevne applikationer, som er normen.