¿Cómo pruebas código que interactúa con bases de datos?

Question

Accepted Answer

Probar código que usa una **base de datos** es desafiante — necesitas comportamiento de datos realista sin problemas de flakiness o lentitud. Los enfoques incluyen **bases de datos de prueba**, **bases de datos en memoria**, **transacciones/rollback**, y **mocking de la capa de datos** — cada uno con sus ventajas y desventajas.

## El desafío

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

## Enfoques

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

## Mejores prácticas

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

## Por qué es importante

Entender cómo probar código que interactúa con bases de datos es valioso porque **la mayoría de las aplicaciones usan bases de datos**, y probar el acceso a datos correctamente es importante pero desafiante, así que es conocimiento práctico útil.

El código de base de datos (queries, acceso a datos, persistencia) necesita pruebas, pero las bases de datos introducen desafíos reales — son más lentas, requieren configuración y limpieza, tienen estado compartido que puede causar interferencia entre pruebas y flakiness, y hacer mocking puede pasar por alto bugs reales en queries.

Entender los **enfoques y sus ventajas y desventajas** es el conocimiento clave: una **base de datos de prueba real** (realista, detectando issues reales de queries y esquema, a menudo ejecutada en un contenedor para consistencia, pero más lenta y necesitando aislamiento), **rollback de transacciones** (envolviendo cada prueba en una transacción y haciendo rollback para estado limpio — un patrón común y efectivo que mantiene pruebas aisladas y razonablemente rápidas), **bases de datos en memoria** (rápidas y fáciles pero potencialmente diferentes de producción, arriesgando issues específicos de prod no detectados), y **mocking de la capa de datos** (pruebas unitarias rápidas e aisladas pero sin probar comportamiento real de base de datos).

Entender cuándo usar cada una — una base de datos real para pruebas de integración de la capa de datos (para detectar bugs reales de queries/esquema), mocking para pruebas unitarias de lógica de negocio sobre la capa de datos — refleja buen criterio sobre balancear realismo, velocidad y aislamiento.

Entender las **mejores prácticas** — **aislar pruebas** (cada una comenzando desde un estado limpio conocido mediante transacciones, truncamiento o una base de datos fresca, para evitar interferencia y flakiness), usar datos de prueba realistas (fixtures/factories), probar comportamiento real de base de datos para la capa de datos, y ejecutar bases de datos limpias en CI — refleja pruebas de base de datos efectivas.

Ya que la mayoría de aplicaciones usan bases de datos y probar acceso a datos correctamente (detectando bugs de queries mientras se mantienen pruebas aisladas, rápidas y confiables) es importante pero desafiante, y ya que entender los enfoques (BD real, transacciones, en memoria, mocking), sus ventajas y desventajas, y mejores prácticas (aislamiento, datos realistas) habilita pruebas de base de datos efectivas, entender cómo probar código que interactúa con bases de datos es conocimiento valioso y práctico — importante para la necesidad común de probar acceso a datos confiablemente, balanceando realismo contra velocidad y aislamiento, una habilidad útil para probar las aplicaciones impulsadas por datos que son la norma.