Como você testa código que interage com bancos de dados?

Question

Accepted Answer

Testar código que usa um **banco de dados** é desafiador — você precisa de comportamento realista dos dados sem flakiness ou lentidão. As abordagens incluem **bancos de dados de teste**, **bancos de dados em memória**, **transações/rollback** e **mocking da camada de dados** — cada uma com trade-offs.

## O desafio

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

## Abordagens

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

## Melhores práticas

```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 que isso importa

Entender como testar código que interage com bancos de dados é valioso porque **a maioria das aplicações usa bancos de dados**, e testar o acesso a dados corretamente é importante mas desafiador, então é conhecimento prático útil.

Código de banco de dados (queries, acesso a dados, persistência) precisa de testes, mas bancos de dados introduzem desafios reais — são mais lentos, exigem setup e cleanup, têm estado compartilhado que pode causar interferência entre testes e flakiness, e fazer mock deles pode perder bugs de queries reais.

Entender as **abordagens e seus trade-offs** é o conhecimento-chave: um **banco de dados de teste real** (realista, capturando query real e problemas de schema, frequentemente rodando em um container para consistência, mas mais lento e precisando isolação), **rollback de transação** (envolvendo cada teste em uma transação e fazendo rollback para estado limpo — um padrão comum e efetivo que mantém testes isolados e razoavelmente rápidos), **bancos de dados em memória** (rápidos e fáceis mas potencialmente diferentes da produção, arriscando perder problemas específicos de prod), e **mocking da camada de dados** (testes unitários rápidos e isolados mas não testando comportamento real do banco).

Entender quando usar cada um — um banco de dados real para testes de integração da camada de dados (para capturar bugs reais de query/schema), mocking para testes unitários da lógica de negócio acima da camada de dados — reflete julgamento sólido sobre balancear realismo, velocidade e isolação.

Entender as **melhores práticas** — **isolar testes** (cada um começando de um estado limpo conhecido via transações, truncation, ou um banco de dados fresco, para evitar interferência e flakiness), usar dados de teste realistas (fixtures/factories), testar comportamento real do banco para a camada de dados, e rodar bancos de dados limpos em CI — reflete testes efetivos de banco de dados.

Já que a maioria das aplicações usa bancos de dados e testar o acesso a dados corretamente (capturando bugs de query enquanto mantém testes isolados, rápidos e confiáveis) é importante mas desafiador, e já que entender as abordagens (DB real, transações, em memória, mocking), seus trade-offs e melhores práticas (isolação, dados realistas) habilita testes efetivos de banco de dados, entender como testar código que interage com bancos de dados é conhecimento valioso e praticamente relevante — importante para a necessidade comum de testar acesso a dados de forma confiável, balanceando realismo contra velocidade e isolação, uma habilidade útil para testar as aplicações data-driven que são a norma.