Gerador de Dados Falsos
Gerado no seu navegador e nunca transmitido. Os nomes são fictícios, os telefones usam a faixa reservada 555-01xx e os endereços IP vêm dos blocos de documentação da RFC 5737 - nada aqui pertence a uma pessoa ou host real.
Nada do que você digita aqui é armazenado, registrado ou compartilhado.
Defina os campos que voce precisa e gere ate 1.000 linhas de dados falsos realistas em JSON, CSV ou comandos INSERT de SQL. Tudo e gerado no seu navegador, entao nada e enviado e nenhum dado pessoal real e usado.
Como usar
- Nomeie cada campo e escolha o tipo de valor que ele deve conter.
- Escolha quantas linhas voce precisa e se quer JSON, CSV ou SQL.
- Clique em Gerar e copie o resultado.
Por que as faixas reservadas importam
Todo valor gerado vem de uma faixa oficialmente reservada para ficção, e isso não é preciosismo - é a diferença entre uma suíte de testes segura de rodar e uma que não é.
Os telefones usam +1-555-01xx, o bloco de cem números que o Plano de Numeração Norte-Americano reserva para uso fictício; o restante do 555 foi liberado para uso real há anos, então o velho hábito de usar qualquer número 555 não é mais seguro. E-mails e URLs usam example.com, example.org e example.net, reservados pela RFC 2606 e garantidos para nunca serem registrados por ninguém. Os endereços IP vêm dos blocos de documentação da RFC 5737, que não são roteados.
A falha que isso evita é bem documentada e continua acontecendo: um teste rodando com fixtures cheias de endereços que parecem reais manda e-mail de verdade para pessoas de verdade, um teste de carga liga para telefones reais, ou um banco de staging populado é apontado para um relay SMTP de produção. Fixtures que não alcançam ninguém resolvem isso na estrutura, e não no procedimento.
Fixtures que realmente encontram bugs
Dados uniformemente razoáveis são confortáveis e pouco úteis. Todo nome com seis a dez letras, toda string em ASCII, todo campo opcional preenchido: uma suíte construída assim passa e não diz nada sobre o que acontece em produção.
Os casos que valem ser adicionados à mão depois de ter uma base: strings vazias e nulls em toda coluna que aceita null, porque seguem caminhos diferentes. Nomes com apóstrofo, hífen, acentos e escritas não latinas, que é onde aparecem bugs de codificação e escape ingênuo. Um valor com exatamente o tamanho da coluna e outro com um caractere a mais. Datas nos limites - fim do mês, fim do ano, 29 de fevereiro, o dia de mudança de horário de verão. Valores duplicados em campos que você supunha únicos. Um único registro muito grande no meio de registros pequenos.
Dados gerados dão volume e formato rapidamente, que é o que você quer para paginação, ordenação, comportamento de índices e renderização. As linhas incômodas são o que você quer para correção, e costumam valer a pena ser escritas de propósito, em vez de torcer para que um gerador as produza.
Os três formatos de saída
JSON é o formato certo quando o destino é código: uma fixture de API, um servidor mock, um script de seed, um arquivo que o teste lê ao iniciar. Os registros saem como um array de objetos com os nomes dos campos como chaves.
CSV serve para caminhos de importação em massa - uma planilha, um COPY no banco, um formulário de upload administrativo - e é a escolha certa quando você quer ver os dados como tabela antes de carregá-los. As ressalvas de sempre do CSV valem do outro lado: um consumidor que adivinha tipos vai tomar as próprias decisões sobre tudo o que parecer número.
SQL gera instruções INSERT simples para o nome de tabela que você informar, uma por linha, que rodam em qualquer cliente sem driver nem script. Strings são escapadas duplicando as aspas, números saem sem aspas, booleanos como TRUE e FALSE, e identificadores que não são palavras simples ficam entre aspas duplas. Para um seed grande, vale envolver a saída numa transação, já que mil instruções individuais fora de uma são lentas na maioria dos bancos.
Não anonimize dados de produção no lugar disso
O atalho tentador quando você precisa de dados de teste realistas é copiar o banco de produção e limpar os campos pessoais. Vale entender por que isso continua dando errado.
Remover nomes e e-mails não desidentifica um conjunto de dados. Combinações de atributos comuns - CEP, data de nascimento, sexo; ou alguns horários e locais - costumam ser únicas para uma pessoa, e as pesquisas sobre reidentificação de bases supostamente anônimas são extensas e consistentes. Enquanto isso, a cópia limpa é uma base de produção com fidelidade total, vivendo num ambiente com controles de acesso mais fracos, acesso mais amplo de desenvolvedores e backups que ninguém acompanha.
Gerar a partir do schema evita a categoria inteira de problemas. Os dados têm o formato certo e nenhuma origem, então um vazamento do staging é um incidente sobre nada. Quando você realmente precisa de distribuições parecidas com as de produção, a versão defensável é modelar as estatísticas e gerar a partir do modelo, e não transformar os registros.
Projetar um conjunto de dados em vez de preencher colunas
Dados de teste realistas não são dados aleatórios; são dados cujo formato bate com o de produção. Tabelas reais são assimétricas: a maioria dos clientes tem um pedido e um punhado tem milhares, a maioria dos documentos é curta e um é enorme, a maioria das sessões dura um minuto e algumas duram um dia. Uma fixture em que todo cliente tem exatamente três pedidos nunca vai revelar a consulta que desmorona no cliente com quatro mil.
O volume importa pelo mesmo motivo. Paginação, ordenação e comportamento de índice são invisíveis com cinquenta linhas e óbvios com cinquenta mil, e uma página que renderiza instantaneamente com uma lista curta pode levar segundos com uma lista realista. Gerar uma ordem de grandeza a mais do que você espera é o teste de carga mais barato que existe.
A integridade referencial é a terceira peça. Pedidos precisam de clientes que existam, comentários precisam de posts, e registros filhos precisam de pais com datas plausíveis - um pedido feito antes de o cliente se cadastrar é uma linha que vai confundir todo relatório construído sobre ela depois.
Seed, determinismo e repetibilidade
Um teste que gera dados aleatórios novos a cada execução falha de forma intermitente, e uma falha intermitente é pior que uma constante porque ninguém consegue reproduzi-la. A disciplina usual é uma seed fixa: a mesma sequência a cada execução, para que a falha seja repetível e um bisect faça sentido.
Isso entra em conflito com o desejo de dados variados, e o meio-termo em que a maioria dos times se acomoda é um gerador com seed cuja seed é impressa na saída do teste. As execuções são reproduzíveis quando você precisa e variadas ao longo do tempo, e quando uma combinação rara quebra alguma coisa, a seed no log reconstrói o caso exatamente.
Scripts de seed também devem ser idempotentes. Rodar o seed duas vezes deve deixar o banco no mesmo estado em vez de dobrar cada tabela, o que na prática significa truncar antes ou fazer upsert por uma chave natural. Um desenvolvedor que precisa derrubar o banco para popular de novo vai evitar popular de novo, e dados locais desatualizados são uma categoria de bug por si só.
Fixtures, factories e snapshots
Três padrões dominam, e resolvem problemas diferentes. Fixtures são arquivos estáticos carregados antes de um teste: previsíveis, fáceis de ler e trabalhosos de manter, porque uma mudança de schema significa editar todos os arquivos. Factories constroem objetos em código com defaults sensatos e sobrescritas por teste, então um teste declara apenas os campos com que se importa - a abordagem amplamente usada na maioria das suítes modernas.
Snapshots capturam a saída de uma função e afirmam que ela não mudou. São excelentes para renderização e serialização, e perigosos quando ninguém lê o diff: um snapshot atualizado que consagra um bug é um modo de falha comum em suítes grandes.
Dados gerados do tipo que esta ferramenta produz ficam por baixo dos três. Eles preenchem o volume - os milhares de linhas que tornam desempenho e paginação realistas - enquanto os registros específicos e complicados são escritos à mão, porque o caso que quebrou a produção no mês passado merece ser declarado explicitamente, em vez de torcer para que um gerador o reproduza.
Por que copiar dados de produção continua dando errado
Pegar um dump de produção e apagar os nomes parece o caminho mais rápido para dados realistas, e falha por razões estruturais, não procedimentais. Remover identificadores diretos não desidentifica um conjunto de dados: combinações de atributos comuns como CEP, data de nascimento e sexo são frequentemente únicas para uma pessoa, e a pesquisa sobre reidentificação de conjuntos de dados supostamente anônimos é extensa e consistente.
O problema operacional é separado e igualmente sério. A cópia higienizada é um conjunto de dados de produção com fidelidade total vivendo em um ambiente com controles de acesso mais fracos, acesso mais amplo de desenvolvedores e backups que ninguém acompanha. Sob o GDPR, dados pseudonimizados continuam sendo dados pessoais e continuam dentro do escopo; esta é uma observação geral, e não aconselhamento jurídico, e os detalhes dependem da sua jurisdição e do seu encarregado de proteção de dados.
Gerar a partir do schema contorna a categoria inteira. Os dados têm o formato certo e nenhuma procedência, então um vazamento no staging é um incidente sobre coisa nenhuma. Onde distribuições parecidas com as de produção são realmente necessárias, a versão defensável é modelar as estatísticas e gerar a partir do modelo, em vez de transformar registros reais.
Carregar a saída onde ela precisa chegar
Para um banco de dados, a saída SQL roda em qualquer cliente sem driver, e envolvê-la em uma transação deixa um seed grande dramaticamente mais rápido - mil comandos individuais fora de uma transação são lentos em quase todo motor. Para o PostgreSQL especificamente, um COPY a partir de um CSV supera comandos INSERT por larga margem assim que a contagem de linhas passa de alguns milhares.
Para uma aplicação, JSON costuma ser o alvo certo: um arquivo de fixture que o teste carrega na inicialização, uma resposta para um mock server, ou um script de seed que o ORM consome. Os nomes dos campos saem exatamente como configurados, então fazê-los coincidir com os nomes das propriedades do modelo poupa uma etapa de mapeamento.
CSV é o formato para os caminhos que envolvem uma pessoa - uma planilha para conferir a olho antes de importar, um formulário administrativo de upload, uma ferramenta de importação em massa. Só lembre das ressalvas de sempre do CSV do outro lado: um consumidor que adivinha tipos vai tomar suas próprias decisões sobre qualquer coisa que pareça numérica, e zeros à esquerda em números de referência são a vítima habitual.
Perguntas frequentes
- E seguro versionar os dados gerados no repositorio?
- Sim, e isso e proposital. Os nomes vem de uma lista ficticia, os telefones usam a faixa +1-555-01xx que o plano de numeracao norte-americano reserva para ficcao, e-mails e URLs usam a familia example.com reservada pela RFC 2606, e os enderecos IP vem dos blocos de documentacao da RFC 5737. Nada gerado aqui aponta para um host real nem liga para uma pessoa real.
- Por que nao pedir dados de teste a uma IA?
- Para tres linhas, peca. Para 500 linhas com um schema fixo voce precisa de repetibilidade e nomes de coluna exatos, que e o que um gerador entrega e um chat nao. Tambem e mais rapido trocar o tipo de um campo e gerar de novo do que reescrever o prompt, e a saida aqui nunca sai da sua maquina.
- Qual a diferenca entre dados falsos, de teste e simulados?
- Na pratica, nenhuma - os tres termos nomeiam a mesma coisa e esta pagina atende a todos. O que importa e o formato: registros estruturados com colunas nomeadas e tipadas, ao contrario de texto de preenchimento como o lorem ipsum, que ocupa o layout mas nao pode ser carregado num banco ou numa API.
- Como uso a saida SQL?
- A saida sao comandos INSERT simples contra o nome de tabela que voce informar, um por linha, entao roda em qualquer cliente SQL. Strings sao escapadas dobrando as aspas, numeros ficam sem aspas e booleanos saem como TRUE e FALSE. Nomes de coluna ou tabela que nao sejam identificadores simples recebem aspas duplas.
- Por que o limite e de 1.000 linhas?
- Mil linhas de JSON ja sao cerca de 100KB de texto, que e o ponto em que uma area de texto comeca a ficar lenta. Se precisar de mais, gere em lotes - a coluna de ID recomeca em 1 a cada vez, entao ajuste se for carregar tudo na mesma tabela.
- A aleatoriedade e confiavel?
- Vem de crypto.getRandomValues com amostragem por rejeicao, a mesma fonte sem vies que este site usa para gerar senhas e UUIDs. Isso importa menos para nomes de cidades ficticias do que para senhas, mas manter uma unica implementacao de aleatoriedade significa que ha apenas uma para acertar.
Última atualização:
Inclua os passos, o resultado esperado e o resultado real. Remova segredos e dados pessoais.