Finja Até Conseguir: Um Guia de Dados Mock para Desenvolvedores

Em uma frase

Geradores de dados mock criam, via programação, grandes conjuntos de informações que parecem realistas, mas são falsas, para substituir dados reais de usuários durante o desenvolvimento e teste de software.

O problema que isso resolve

No início, havia "teste". E "teste2". E "asdf". Quando um dev precisava preencher um formulário ou popular um banco de dados para ver se o código funcionava, ele simplesmente metia a mão no teclado até sair alguma coisa. Para um único usuário, tudo bem. Para uma lista de dez usuários? Chato, mas factível. Você acaba com um banco de dados cheio de "Usuário 1", "Usuário 2" e o criativíssimo "Usuário 10".

Essa abordagem desmorona bem rápido. O que acontece quando sua UI precisa lidar com um nome como Maximilian Æon Flux? Seu "Usuário Teste" digitado à mão não te preparou para isso. O que acontece quando sua consulta ao banco de dados precisa ser testada com 50.000 registros, e não 10, para ver se ela tem boa performance? Ninguém tem tempo ou saco para criar 50.000 usuários falsos na mão.

A solução antiga e perigosa era simplesmente pegar uma cópia do banco de dados de produção. Isso é um incêndio de proporções épicas em termos de segurança e privacidade. Expor nomes, e-mails e informações pessoais de clientes reais no notebook menos seguro de um desenvolvedor é um vazamento de dados anunciado, com consequências legais (alô, GDPR e LGPD) que podem afundar uma empresa.

Geradores de dados mock resolvem tudo isso. Eles permitem que você defina a forma dos seus dados uma vez e, em seguida, cospem milhares de registros que parecem reais, mas são totalmente fabricados. É a diferença entre um alfaiate usar um manequim genérico para ajustar um terno versus pegar uma pessoa aleatória na rua. O manequim é previsível, seguro e vem em todos os tamanhos padrão que você precisa para testar.

Como funciona por debaixo dos panos

Pode parecer mágica, mas um gerador de dados mock é apenas uma combinação inteligente de templates, dicionários de dados enormes e aleatoriedade controlada.

### Templates e Placeholders

Na sua essência, um gerador usa um template que você fornece. Geralmente, é um objeto JSON que funciona como uma planta baixa para um único registro. Em vez de valores reais, você usa placeholders especiais que dizem ao gerador que tipo de dado você quer.

Imagine que você precisa gerar um objeto de usuário. Seu template pode ser algo assim:

{
  "userId": "{{datatype.uuid}}",
  "name": "{{person.fullName}}",
  "email": "{{internet.email}}",
  "signupDate": "{{date.past}}",
  "address": {
    "street": "{{location.streetAddress}}",
    "city": "{{location.city}}",
    "zipCode": "{{location.zipCode}}"
  }
}

Cada {{...}} é um placeholder. Você não está dizendo que o nome é "João da Silva"; você está dizendo que quer um nome, e o gerador se vira com o resto. Essa abordagem declarativa é poderosa porque você foca na estrutura, não no conteúdo específico.

### A Magia das Bibliotecas

Então, de onde vêm os nomes, e-mails e cidades? Eles não são invocados do nada. Eles são extraídos de listas e algoritmos pré-compilados gigantescos dentro de bibliotecas de geração de dados falsos (uma famosa no mundo JavaScript é a Faker.js, mas muitas linguagens têm sua própria versão).

Aqui está um resumo simplificado de como ele pode gerar um único registro de usuário a partir do template acima:

{{person.fullName}}: A biblioteca tem listas de milhares de nomes e sobrenomes. Ela escolhe um de cada aleatoriamente e os combina. random(firstNames) -> "Amelia", random(lastNames) -> "Jones". Resultado: "Amelia Jones".
{{internet.email}}: Isso geralmente se baseia em outros campos gerados. Ele pode pegar o "Amelia Jones" que acabou de criar, transformá-lo em amelia.jones e anexar um domínio escolhido aleatoriamente de uma lista (@example.com, @mail.net, etc.). Resultado: amelia.jones@example.com.
{{location.city}}: Simples. A biblioteca tem uma lista enorme de nomes de cidades do mundo todo. Ela escolhe uma. Resultado: "Portsmouth".
{{datatype.uuid}}: Este não usa uma lista. Ele usa um algoritmo bem definido para gerar um Identificador Único Universal (Universally Unique Identifier), como f81d4fae-7dec-11d0-a765-00a0c91e6bf6.

O gerador processa seu template campo por campo, chamando a função apropriada da biblioteca para cada placeholder até que o registro falso inteiro seja construído. Quer 10.000 registros? Ele apenas repete esse processo 10.000 vezes.

### Determinismo e Seeding

Aqui está um detalhe crucial para testes: e se você precisar do mesmo exato conjunto de dados "aleatórios" toda vez que rodar seus testes? Se seu teste espera um usuário chamado "Amelia Jones", mas recebe "Bob Williams" na próxima execução, ele vai falhar. É aqui que entra o "seeding".

Computadores são péssimos em serem verdadeiramente aleatórios. Eles usam algo chamado Gerador de Números Pseudoaleatórios (PRNG). Um PRNG é um algoritmo que produz uma sequência de números que parece aleatória, mas na verdade é completamente determinada por um valor inicial chamado seed (semente).

Se você começar com seed = 123, pode obter a sequência: 5, 8, 2, 1, 10, ...
Se você rodar de novo com seed = 123, obterá a mesma sequência exata: 5, 8, 2, 1, 10, ...
Se você começar com seed = 456, obterá uma sequência totalmente diferente: 9, 4, 7, 3, 3, ...

Ao fornecer um seed para o seu gerador de dados mock, você garante que, toda vez que ele for executado, ele escolherá o mesmo nome "aleatório", o mesmo sobrenome "aleatório" e a mesma cidade "aleatória" de suas listas, na mesma ordem. Isso lhe dá um conjunto de dados que é ao mesmo tempo realista e perfeitamente reproduzível, que é o santo graal para escrever testes automatizados estáveis e confiáveis.

Histórias do mundo real

A teoria é ótima, mas vamos ver a coisa na prática.

### O Caso do Card de Usuário que Explodiu

Uma desenvolvedora frontend, vamos chamá-la de Priya, foi encarregada de construir um novo e belo card de perfil de usuário para um aplicativo de mídia social. Ela criou o CSS meticulosamente, usando "Jane Doe" e um endereço padrão @gmail.com como dados de teste. O card estava perfeito, com precisão de pixel. O nome e o e-mail cabiam perfeitamente em uma linha. Ela lançou a feature.

No dia seguinte, os relatórios de bug começaram a chegar. Um usuário chamado Dr. Alessandro O'Connell-Schäfer se inscreveu. Seu nome quebrou o layout, envolvendo-se em três linhas e empurrando sua foto de perfil para fora do card. Outro usuário da Islândia tinha um caractere não-ASCII em seu nome, que foi renderizado como um ? ilegível. O layout era uma bagunça.

A Lição: Seus dados de teste bonitinhos e fixos no código são uma mentira. Um gerador de dados mock teria produzido rapidamente nomes de vários comprimentos, com hifens, apóstrofos e caracteres internacionais, revelando essas fraquezas da UI muito antes de chegarem a um usuário real.

### O Pesadelo da Performance na Paginação

Uma equipe de backend estava lançando um novo site de e-commerce. Um desenvolvedor, Ben, era responsável pelo endpoint da API /products. Ele criou uma dúzia de produtos de teste em seu banco de dados local: "Livro de Teste", "Camisa de Teste", etc. Ele escreveu o código para buscar os produtos, adicionou paginação (25 itens por página) e tudo funcionou perfeitamente. A API respondia em 20 milissegundos.

O site foi lançado. Em uma semana, o catálogo de produtos cresceu para 30.000 itens. De repente, os usuários começaram a relatar que as páginas de produtos estavam demorando uma eternidade para carregar ou dando timeout. A consulta ao banco de dados, que era instantânea para 12 produtos, agora estava varrendo a tabela gigantesca e levando mais de 15 segundos para ser concluída. O aplicativo estava travando.

A Lição: Funcionalidade não é performance. Para testar a performance, você precisa de um volume realista de dados. Em vez de criar 12 produtos na mão, Ben poderia ter usado um gerador de dados mock para criar 50.000 produtos falsos em minutos. Isso teria exposto imediatamente a consulta lenta durante o desenvolvimento, levando-o a adicionar um índice de banco de dados necessário antes que isso se tornasse uma crise em produção.

### O Susto de Conformidade com a Privacidade de Dados

Uma pequena startup estava em uma correria maluca para preparar uma demo para um grande investidor em potencial. Eles queriam que a demo parecesse o mais real possível. Um desenvolvedor júnior, tentando ser prestativo, teve uma ideia "brilhante": ele se conectou ao banco de dados de produção, copiou toda a tabela users (cerca de 2.000 clientes reais) e a carregou no ambiente de homologação (staging). Os dados eram reais, então a demo ficou ótima!

Uma semana depois, um engenheiro sênior descobriu o que havia acontecido. O pânico se instaurou. Nomes, e-mails e números de telefone de clientes reais estavam em um servidor de homologação menos seguro, acessível a toda a equipe de desenvolvimento. Isso foi uma violação clássica das leis de privacidade de dados como a GDPR (e a LGPD no Brasil). Se esses dados tivessem vazado, a empresa poderia ter enfrentado multas incapacitantes e uma perda total de confiança dos usuários. Eles se livraram de uma fria, mas a limpeza foi estressante и cara.

A Lição: Nunca, jamais, em hipótese alguma use dados reais de clientes para desenvolvimento, testes ou demos. O risco é astronômico. Um gerador de dados mock fornece uma alternativa segura, ética e legal que imita a estrutura dos seus dados de produção sem expor uma única pessoa real.

Erros e armadilhas comuns

Ignorar os edge cases. Gerar milhares de nomes no estilo "João da Silva" é fácil. Mas e nomes muito longos? Nomes com apóstrofos? Endereços com caracteres estranhos? E-mails com o símbolo +? Uma boa estratégia de mocking inclui gerar dados que testem especificamente esses casos extremos (edge cases), não apenas o caminho feliz.
Esquecer dos relacionamentos. É fácil gerar uma lista de 100 usuários e uma lista de 1000 pedidos. Mas, na realidade, esses pedidos pertencem a esses usuários. Um erro comum é gerar dados desconectados. Bons setups de mocking permitem manter relacionamentos, por exemplo, gerando primeiro um conjunto de userIds e, em seguida, escolhendo a partir desse conjunto ao gerar os orders para garantir a integridade dos dados.
Criar dados não determinísticos para testes. Se seus testes automatizados rodam contra um gerador de mock que produz dados diferentes a cada vez, você terá testes "flaky" (instáveis) que falham aleatoriamente. É um pesadelo para debugar. Sempre use um "seed" no seu gerador para ambientes de teste para garantir que seus dados de teste sejam 100% reproduzíveis.
Assumir uma distribuição uniforme. Se você está gerando um campo status e escolhe aleatoriamente entre ["active", "pending", "suspended"], você terá cerca de 33% de cada. Os dados do mundo real raramente são tão organizados. Você pode ter 98% de usuários ativos, 1,9% pendentes e 0,1% suspensos. Muitos geradores permitem que você especifique pesos para modelar com mais precisão as distribuições de dados do mundo real.

Por que isso deve estar no seu radar

Você deve recorrer a um gerador de dados mock sempre que precisar de dados que ainda não existem, que não deveriam ser usados ou que são muito chatos de criar na mão.

Pense nisso quando você estiver:

Construindo uma nova feature e as tabelas do banco de dados ainda estão vazias.
Escrevendo testes automatizados e precisa de entradas de dados consistentes и previsíveis.
Testando a performance de uma API ou consulta de banco de dados e precisa simular milhares ou milhões de registros.
Projetando uma UI e quer testá-la ao extremo com strings longas, caracteres estranhos e conteúdo variado.
Criando uma demo de produto ou screencast e precisa de dados com aparência realista sem expor informações privadas.
Fazendo o onboarding de um novo dev e quer dar a ele um banco de dados populado para trabalhar sem conceder acesso aos dados de produção.

É uma ferramenta fundamental para o desenvolvimento de software moderno, seguro e eficiente.

Para se aprofundar

Faker.js - A documentação de uma das bibliotecas de geração de dados mock mais populares e completas do ecossistema JavaScript. Um ótimo lugar para ver a enorme variedade de dados que podem ser criados.
Wikipedia: Test Data Generation - Uma visão geral de alto nível do conceito, sua história e diferentes abordagens para o problema.
Wikipedia: Pseudorandom Number Generator (PRNG) - A base teórica de como dados "aleatórios" podem se tornar reproduzíveis através do seeding.
GDPR.eu: What is GDPR? - Uma explicação clara sobre o regulamento de privacidade de dados da UE. Entender as regras ajuda a esclarecer por que usar dados de produção para testes é tão arriscado.
Database Seeding (Laravel Docs) - Um excelente exemplo de como um framework web popular integra a geração de dados mock (através de "seeders" e "factories") diretamente no fluxo de desenvolvimento. Os conceitos são transferíveis para qualquer linguagem ou framework.