---
title: "Um ambiente de teste com dados semeados vale mais do que uma cópia de produção"
description: "Todo o nosso ambiente local é um Postgres dentro do próprio processo, que arranca vazio, aplica as migrações reais e se enche sozinho com um salão fictício convincente. Sem credenciais de produção nos portáteis, sem dados reais de clientes nas capturas de ecrã, e uma demonstração que nunca fica velha."
url: "https://bookatu.com/pt-pt/blog/seeded-sandbox-instead-of-prod-data"
language: "pt"
section: "Blog"
category: "Engenharia"
author: "A equipa de engenharia do Bookatu"
published: "2026-07-13"
updated: "2026-07-13"
tags: ["ambiente de desenvolvimento local", "dados semeados", "postgres embebido", "privacidade dos dados de teste", "experiência do programador"]
---

# Um ambiente de teste com dados semeados vale mais do que uma cópia de produção

Todo o nosso ambiente local é um Postgres dentro do próprio processo, que arranca vazio, aplica as migrações reais e se enche sozinho com um salão fictício convincente. Sem credenciais de produção nos portáteis, sem dados reais de clientes nas capturas de ecrã, e uma demonstração que nunca fica velha.

> **Em resumo**
>
> - O desenvolvimento local corre um Postgres embebido, dentro do próprio processo. Com as credenciais em branco, é fisicamente impossível tocar em produção por engano.
> - A base de dados é reconstruída a partir dos mesmos ficheiros de migração que produção usa, por isso as divergências de esquema aparecem num portátil antes de aparecerem num lançamento.
> - Um script de sementeira cria um negócio credível: serviços, equipa, clientes, marcações, stock. Realista o suficiente para encontrar erros a sério.
> - Os dados fictícios podem ir para qualquer lado: capturas de ecrã, artigos de blog, relatórios de erros, demonstrações. Os dados de produção não podem ir para lado nenhum.

Há um momento na vida de todas as equipas pequenas em que alguém sugere apontar o desenvolvimento local para uma cópia da base de dados de produção, porque os dados fictícios parecem finos e os erros a sério só acontecem com registos reais. É uma ideia tentadora com uma longa cauda de arrependimento: credenciais espalhadas por portáteis, nomes de clientes em capturas de ecrã, um trabalho de teste de emails que um dia encontra endereços reais. Fomos pelo caminho oposto e nunca mais olhámos para trás.

## Um Postgres inteiro dentro do processo

As versões embebidas do Postgres ficaram genuinamente boas. A nossa aplicação decide no arranque: se existirem credenciais reais de base de dados no ambiente, usa a base de dados alojada; se estiverem em branco, levanta um Postgres dentro do processo que vive numa pasta local. As máquinas de desenvolvimento simplesmente nunca têm as credenciais, por isso o pior que acontece a um portátil mal configurado é uma base de dados vazia acabada de criar, e não um incidente em produção.

```js
// Choose the database at runtime. Blank env = embedded, local, harmless.
function makeDb() {
  const url = process.env.DATABASE_URL;
  if (url) return connectHosted(url);
  // In-process Postgres persisted to a local folder
  const client = new EmbeddedPostgres('./.pgdata');
  return drizzle(client, { schema });
}
```

O caminho da reconstrução conta tanto como o motor. Recriamos a base de dados local aplicando os mesmos ficheiros de migração que produção correu, por ordem, desde o primeiro. Essa única decisão apanhou uma família inteira de erros de graça: uma migração que assumia uma coluna de um ficheiro posterior, uma alteração de esquema que funcionava contra uma cópia antiga mas não de raiz. Se o portátil não consegue construir o esquema a partir do histórico, o lançamento seguinte também não conseguiria.

## Semeie um negócio, não linhas

A diferença entre dados fictícios inúteis e úteis é a narrativa. O nosso script de sementeira não insere dez utilizadores chamados teste. Cria um salão com nome, equipa com especialidades, serviços com preços e durações honestos, clientes com histórico de visitas, marcações por vir, produtos de retalho com níveis de stock e um registo de movimentos por trás. As páginas parecem habitadas, o que significa que os erros de layout, os estados vazios e os cortes de texto desajeitados aparecem como apareceriam a um cliente real.

![Um painel de marcações cheio de dados de exemplo semeados: receita, marcações e atividade de clientes](https://bookatu.com/blog/shots/dashboard-light.png)

*Tudo nesta captura de ecrã é ficção. É exatamente isso que a torna publicável.*

Essa última propriedade é fácil de subestimar. Todas as capturas de ecrã da nossa documentação, do nosso blog e dos nossos relatórios de erros vêm do ambiente semeado. Ninguém tem de olhar de perto para uma imagem a perguntar se escapou o nome de algum cliente, porque não há nomes de clientes para escapar. O processo de anonimização mais seguro é não haver nada para anonimizar.

## O que é preciso acertar

- Faça do caminho seguro o caminho por defeito. Os programadores devem ter de sair do caminho para chegar a dados reais, e não para os evitar.
- Neutralize também os efeitos secundários: as chaves de email, de pagamentos e de armazenamento ficam em branco localmente, por isso um ciclo sobre clientes semeados nunca pode enviar mensagens a uma pessoa real.
- Semeie os estados que teme: a conta acabada de criar, o dia com a agenda cheia, o produto esgotado, o cliente com uma única visita há anos.
- Mantenha a sementeira na revisão de código. Quando uma funcionalidade acrescenta uma tabela, a sementeira cresce com ela, ou o ambiente apodrece em silêncio.

O retorno acumula-se. Os colegas novos correm dois comandos e ficam com um negócio a funcionar para mexer. O controlo de qualidade visual pode fotografar todas as páginas sem revisão de privacidade. E o ambiente de demonstração está sempre a cinco minutos de estar impecável, porque impecável é só uma reconstrução.

> Os dados de produção respondem a perguntas. Os dados semeados deixam-no fazê-las em segurança.