Gerador de Pessoas (ficha completa fictícia)

Montar uma pessoa de teste chamando um gerador para cada campo produz um registro que não sobrevive à primeira validação cruzada: alguém que mora em Curitiba, com CEP de Recife e DDD do Acre. Aqui a ficha nasce de uma escolha só — a unidade federativa — e o resto é derivado dela.

O que a UF amarra

• CPF: o nono dígito recebe o código da região fiscal do estado escolhido. Paraná e Santa Catarina usam 9, São Paulo usa 8, Rio Grande do Sul usa 0 — a tabela completa está no guia sobre o nono dígito e a região fiscal.
• CEP: sorteado dentro da faixa oficial daquela UF. No Paraná, entre 80000-000 e 87999-999.
• Cidade: capital ou outro município grande do mesmo estado, nunca um nome solto.
• Telefone: DDD da lista daquela UF (no Paraná, de 41 a 46), em formato de celular com o nono dígito.

Nome, sexo, data de nascimento entre 18 e 80 anos, nome da mãe, RG e e-mail completam o registro. O nome da mãe reaproveita os sobrenomes do titular, detalhe que some quando a massa é montada campo a campo e que aparece em qualquer tela que confere filiação. CPF e RG saem dos mesmos geradores dedicados, com dígito verificador calculado por módulo 11.

Onde a incoerência estraga o teste

Boa parte dos formulários brasileiros consulta o CEP e preenche cidade e UF sozinha. Uma ficha incoerente faz esse preenchimento sobrescrever o que o teste digitou, e o caso falha por um motivo que não tem nada a ver com a regra em avaliação. O mesmo vale para roteamento de atendimento por DDD, alíquota por estado, frete por região e relatórios agregados por UF: essas regras leem a combinação dos campos, não cada um isolado. Quando um teste quebra, você quer que a causa esteja no código, não na massa.

Os endereços gerados saem apenas em seis domínios: example.com, example.org, example.net, teste.example, exemplo.test e mail.invalid. Os três primeiros são nomes reservados para documentação; os de topo .test, .example e .invalid são reservados justamente para documentação e teste, e não são delegados na raiz do DNS. Nenhum deles entrega e-mail.

A razão é prática. Ambiente de homologação dispara e-mail de boas-vindas, redefinição de senha, aviso de cobrança e notificação de status. Se a massa usar domínios de provedores reais, um endereço sorteado pode existir e pertencer a alguém que nunca ouviu falar do seu sistema — e passa a receber mensagens transacionais dele. Com domínio reservado, a entrega morre na resolução do MX e nada chega a uma caixa de verdade.

O efeito colateral é útil: ao apontar o SMTP de homologação para essa massa, todo envio indevido vira bounce, o que expõe rotinas que estavam mandando e-mail quando não deviam.

Um cuidado: se o seu validador de e-mail consulta registro MX ou usa lista de domínios descartáveis, ele vai recusar esses endereços. Em teste, valide apenas o formato, ou reserve um domínio próprio sem MX (algo como teste.suaempresa.com.br) e troque o sufixo ao carregar a massa.

Cada ficha pode ser copiada campo a campo, inteira em texto, em JSON ou em XML. Quando o lote tem mais de uma pessoa, aparece um grupo de cópia do conjunto completo nos três formatos — o limite é de 25 fichas por geração. Os rótulos da tela viram chaves em camelCase sem acento: Nome da mãe vira nomeDaMae e Cidade/UF vira cidadeUf.

[
  {
    "nome": "Ana Ribeiro Castro",
    "cpf": "123.456.789-09",
    "rg": "24.598.973-0",
    "nascimento": "14/03/1988",
    "sexo": "Feminino",
    "nomeDaMae": "Cláudia Ribeiro Castro",
    "email": "ana.castro42@example.org",
    "celular": "(41) 98461-2037",
    "cep": "80230-450",
    "endereco": "Rua das Acácias, 412 — Jardim América",
    "cidadeUf": "Curitiba/PR"
  }
]

A saída XML usa <pessoas> como raiz e um <pessoa> por ficha, com os mesmos nomes de chave como elementos e os caracteres &, < e > escapados. Serve para alimentar integração legada que ainda fala SOAP ou arquivo posicional convertido.

<?xml version="1.0" encoding="UTF-8"?>
<pessoas>
  <pessoa>
    <nome>Ana Ribeiro Castro</nome>
    <cpf>123.456.789-09</cpf>
    <rg>24.598.973-0</rg>
    <nascimento>14/03/1988</nascimento>
    <sexo>Feminino</sexo>
    <nomeDaMae>Cláudia Ribeiro Castro</nomeDaMae>
    <email>ana.castro42@example.org</email>
    <celular>(41) 98461-2037</celular>
    <cep>80230-450</cep>
    <endereco>Rua das Acácias, 412 — Jardim América</endereco>
    <cidadeUf>Curitiba/PR</cidadeUf>
  </pessoa>
</pessoas>

Para virar seed de verdade, esse JSON precisa ser congelado num arquivo versionado em vez de regerado a cada execução — caso contrário o teste passa hoje e falha amanhã com outro sorteio. O guia sobre fixtures, seeds e faker trata dessa escolha entre massa fixa e massa gerada, e de quando cada uma compensa.

Os nomes vêm de listas de prenomes e sobrenomes comuns no Brasil, então um nome gerado pode coincidir com o de alguém real. O conjunto, não: o CPF e o RG são sorteados dentro do espaço de números com dígito verificador correto, sem consultar nenhuma base, e não existe caminho de volta de uma ficha para uma pessoa. Nada do que sai daqui é dado pessoal.

Ter dígito verificador correto também não significa existir. O CPF da ficha passa em qualquer rotina de validação de formato, mas não tem inscrição na Receita Federal — situação cadastral só a própria Receita informa, na consulta oficial.

O que a ficha não serve para fazer: abrir conta, preencher cadastro que exija identificação verdadeira, assinar documento em nome de outra pessoa, contornar verificação de idade ou enganar antifraude. Passar-se por outra pessoa ou apresentar identificação falsa é crime, e o fato de o número fechar a conta do dígito verificador não muda isso. Os limites estão detalhados em uso permitido e proibido.

No sentido oposto, trocar um dump de produção por fichas fictícias em desenvolvimento e homologação reduz a superfície de exposição de dados reais em ambientes que costumam ter menos controle de acesso, log e retenção. O guia sobre LGPD e dados de teste detalha esse raciocínio, incluindo anonimização e minimização.