Um dataset com campos gerados de forma totalmente independente entre si serve tão bem quanto um com campos consistentes?

Não para todos os propósitos: se idade e data de nascimento, ou nome e e-mail, forem gerados sem relação entre si, um teste que valida a coerência exibida desses campos não vai detectar um bug real de exibição, porque os próprios dados de teste já eram incoerentes. Este gerador aplica a mesma lógica de consistência do gerador de Pessoas a cada linha.

É seguro rodar o SQL exportado diretamente num banco de produção?

Não é essa a finalidade da ferramenta — os dados são fictícios e pensados para ambientes de desenvolvimento, teste ou homologação. Rodar em produção misturaria dados sintéticos com dados reais de forma irreversível sem um processo de limpeza planejado, o que foge do propósito de uma ferramenta de dados de teste.

Gerador de Dataset em Massa

Documentação técnica

Gerador de Dataset em Massa: orquestrando todos os outros geradores de uma vez

Esta ferramenta não introduz nenhum algoritmo novo — ela é uma camada de orquestração sobre os geradores individuais já documentados no resto deste site (CPF, CNPJ, RG, telefone, CEP, UUID, senha, data de nascimento), combinando os campos escolhidos em linhas de uma tabela e exportando o resultado em três formatos: CSV, JSON ou SQL. O valor está em resolver um problema que aparece na prática de testes de forma recorrente: popular um banco de dados ou uma planilha de teste com centenas de registros plausíveis, sem escrever um script específico para cada situação.

Por que os três formatos de exportação exigem tratamento diferente

CSV, JSON e SQL não são só "a mesma tabela em roupagens diferentes" — cada formato tem suas próprias regras de escaping que, se ignoradas, corrompem o arquivo de saída. Um nome com vírgula ou aspas precisa de escaping específico em CSV (RFC 4180: campos com vírgula, aspas ou quebra de linha devem ser envolvidos em aspas duplas, com aspas internas duplicadas); em JSON, o mesmo valor precisa de escaping de string diferente (barra invertida antes de aspas, sequências Unicode para caracteres de controle); em SQL, um INSERT mal escapado com aspas simples não tratadas é literalmente a classe de vulnerabilidade mais clássica de SQL Injection, mesmo em um script gerado para uso interno de teste. O gerador cuida dessas três formas de escaping separadamente, para que o arquivo exportado seja válido no formato de destino sem edição manual.

Consistência entre linhas, não só dentro de cada linha

Cada linha do dataset reaproveita a mesma lógica de consistência já documentada no gerador de Pessoas — idade derivada da data de nascimento, e-mail derivado do nome — mas aplicada em lote, com cada linha representando um registro internamente coerente e distinto dos demais. Isso é o que diferencia um dataset de teste útil de uma tabela de valores aleatórios desconexos: um dataset de 200 linhas onde cada linha "faz sentido" individualmente é muito mais representativo do que um sistema real vai efetivamente receber do que 200 linhas de campos sorteados de forma totalmente independente uns dos outros.

Uso em testes de carga, migração e importação em lote

Testar um endpoint de importação em massa, validar performance de índice de banco sob volume realista, ou popular um ambiente de desenvolvimento local logo após rodar migrations são os três casos de uso mais diretos: exportar em SQL para rodar direto num banco de desenvolvimento, em CSV para testar um fluxo de importação de planilha, ou em JSON para alimentar um endpoint de API em teste de carga — sem escrever nenhum script de seed personalizado para cada cenário.