Wie testest du Code, der mit Datenbanken interagiert?

Question

Accepted Answer

Das Testen von Code, der eine **Datenbank** verwendet, ist anspruchsvoll — du benötigst realistisches Datenverhalten ohne Flakiness oder Langsamkeit. Ansätze umfassen **Test-Datenbanken**, **In-Memory-Datenbanken**, **Transaktionen/Rollback** und **Mocking der Datenschicht** — jeder mit Vor- und Nachteilen.

## Die Herausforderung

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

## Ansätze

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

## Warum es wichtig ist

Zu verstehen, wie man Code testet, der mit Datenbanken interagiert, ist wertvoll, weil **die meisten Anwendungen Datenbanken verwenden**, und das korrekte Testen des Datenzugriffs wichtig, aber herausfordernd ist, daher ist es praktisches und nützliches Wissen.

Datenbankcode (Abfragen, Datenzugriff, Persistierung) muss getestet werden, aber Datenbanken führen echte Herausforderungen ein — sie sind langsamer, erfordern Setup und Cleanup, haben gemeinsame Zustände, die zu Testinterferenzen und Flakiness führen können, und das Mocking von ihnen kann echte Query-Bugs übersehen.

Das Verständnis der **Ansätze und ihrer Vor- und Nachteile** ist das Schlüsselwissen: eine **echte Test-Datenbank** (realistisch, erfasst tatsächliche Query- und Schema-Probleme, oft in einem Container für Konsistenz, aber langsamer und benötigt Isolation), **Transaktions-Rollback** (jede Test in einer Transaktion umhüllen und rollback für sauberen Zustand — ein häufiges, effektives Pattern, das Tests isoliert und angemessen schnell hält), **In-Memory-Datenbanken** (schnell und einfach, aber möglicherweise abweichend von Production, risikiert verpasste produktionsspezifische Probleme), und **Mocking der Datenschicht** (schnelle isolierte Unit-Tests, aber nicht das Testen echten Datenbankverhaltens).

Zu verstehen, wann man welches einsetzt — eine echte Datenbank für Integrationstests der Datenschicht (um echte Query/Schema-Bugs zu finden), Mocking für Unit-Tests der Geschäftslogik oberhalb der Datenschicht — spiegelt fundiertes Urteilsvermögen über das Ausgleichen von Realismus, Geschwindigkeit und Isolation wider.

Das Verständnis der **Best Practices** — **Tests isolieren** (jeder startet aus einem bekannten sauberen Zustand über Transaktionen, Truncation oder eine frische Datenbank, um Interferenz und Flakiness zu vermeiden), realistisch Testdaten verwenden (Fixtures/Factories), echtes Datenbank-Verhalten für die Datenschicht testen, und saubere Datenbanken in CI ausführen — spiegelt effektives Datenbank-Testing wider.

Da die meisten Anwendungen Datenbanken verwenden und das korrekte Testen des Datenzugriffs (Query-Bugs erfassen, während Tests isoliert, schnell und zuverlässig bleiben) wichtig, aber herausfordernd ist, und da das Verständnis der Ansätze (echte DB, Transaktionen, In-Memory, Mocking), ihrer Vor- und Nachteile und Best Practices (Isolation, realistische Daten) effektives Datenbank-Testing ermöglicht, ist das Verständnis, wie man Code testet, der mit Datenbanken interagiert, wertvoll und praktisch relevantes Wissen — wichtig für das häufige Bedürfnis, Datenzugriff zuverlässig zu testen, Realismus gegen Geschwindigkeit und Isolation auszugleichen, eine nützliche Fähigkeit für das Testen der datengestützten Anwendungen, die die Norm sind.