Hoe test je code die met databases interageert?

Question

Accepted Answer

Testing van code die een **database** gebruikt is uitdagend — je hebt realistisch gegevensgedrag nodig zonder instabiliteit of traagheid. Benaderingen omvatten **testdatabases**, **in-memory databases**, **transacties/rollback** en **mocking van de datalaag** — elk met afwegingen.

## De uitdaging

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

## Benaderingen

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

## Best practices

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

## Waarom het belangrijk is

Het begrijpen hoe je code die met databases interageert test, is waardevol omdat **de meeste applicaties databases gebruiken** en het correct testen van gegevenstoegang belangrijk maar uitdagend is, dus het is praktische kennis.

Database-code (queries, gegevenstoegang, persistentie) moet getest worden, maar databases introduceren echte uitdagingen — ze zijn langzamer, vereisen setup en cleanup, hebben gedeelde status die teststoringen en instabiliteit kan veroorzaken, en het mocken ervan kan echte querybug's missen.

Het begrijpen van de **benaderingen en hun afwegingen** is de sleutelkennis: een **echte testdatabase** (realistisch, vangt werkelijke query- en schemaproblemen, wordt vaak in een container uitgevoerd voor consistentie, maar langzamer en vereist isolatie), **transactierollback** (elk test in een transactie verpakken en terugdraaien voor schone state — een veelgebruikt, effectief patroon dat tests geïsoleerd en redelijk snel houdt), **in-memory databases** (snel en eenvoudig maar potentieel verschillend van productie, riskant voor gemiste productiespecifieke problemen) en **mocking van de datalaag** (snelle geïsoleerde unit tests maar niet het testen van echt databasegedrag).

Begrijpen wanneer je elk moet gebruiken — een echte database voor integratietesting van de datalaag (om echte query- en schemabug's te vangen), mocking voor unit-testen van bedrijfslogica boven de datalaag — weerspiegelt goed oordeel over het balanceren van realisme, snelheid en isolatie.

Het begrijpen van de **best practices** — **tests isoleren** (elk begint met een bekende schone status via transacties, truncatie of een verse database, om storingen en instabiliteit te voorkomen), realistische testgegevens gebruiken (fixtures/factories), echt databasegedrag testen voor de datalaag en schone databases in CI uitvoeren — weerspiegelt effectief databasetesting.

Omdat de meeste applicaties databases gebruiken en het correct testen van gegevenstoegang (query-bugs vangen terwijl tests geïsoleerd, snel en betrouwbaar blijven) belangrijk maar uitdagend is, en omdat het begrijpen van de benaderingen (echte DB, transacties, in-memory, mocking), hun afwegingen en best practices (isolatie, realistische gegevens) effectief databasetesting mogelijk maakt, is het begrijpen hoe je code die met databases interageert test waardevol, praktisch relevant — belangrijk voor de veel voorkomende behoefte om gegevenstoegang betrouwbaar te testen, realisme tegen snelheid en isolatie af te wegen, een nuttige vaardigheid voor het testen van de gegevensgestuurde applicaties die de norm zijn.