Dados de identidade para teste são registros fabricados que ocupam os mesmos campos de uma pessoa: nome, documento, data de nascimento, endereço e telefone. Eles existem para que um sistema possa ser exercitado sem que nenhum dado de gente de verdade entre no ambiente. Neste texto, mostramos o que essas amostras são, em que momento você precisa delas e o que vale checar antes de confiar em um conjunto.
O que é uma identidade sintética, na prática?
Uma identidade sintética é um conjunto de valores gerados por algoritmo. O nome é montado a partir de listas, o número de documento segue a estrutura do país escolhido, a data de nascimento cai dentro de uma faixa plausível e o endereço pertence a uma divisão administrativa real. Nada disso foi copiado de um cadastro: cada campo é construído, e o conjunto existe só como dado de teste.
Isso a distingue de uma identidade real, que pertence a uma pessoa e carrega consequências. Uma identidade sintética pode ser apagada, duplicada, publicada em um repositório ou usada em mil execuções seguidas sem que ninguém seja afetado. É essa ausência de dono que a torna útil.
Vale ter clareza sobre um ponto desde o começo: os registros gerados por estas ferramentas servem apenas para testes e não podem ser usados para se passar por outra pessoa. Eles não são aceitos por nenhuma verificação de identidade, serviço de abertura de conta ou processo que exija uma pessoa real, e não devem ser apresentados como se fossem de alguém.
Por que dado real não pode entrar no ambiente de teste?
A tentação é óbvia: se o ambiente de produção já tem cadastros completos, parece mais rápido copiar uma parte deles para o banco de homologação. O problema é o que essa cópia cria.
- O ambiente de teste costuma ter controle de acesso mais frouxo, mais gente com permissão e menos registro de quem consultou o quê.
- Uma cópia esquecida em uma máquina de desenvolvimento sobrevive a qualquer política de retenção.
- Dados de pessoas reais em ambiente de teste tendem a reaparecer em capturas de tela, relatórios de erro e conjuntos de exemplo compartilhados entre equipes.
- Nome, documento, nascimento, endereço e telefone são dados pessoais mesmo quando ninguém os está usando para tomar uma decisão.
Nenhuma dessas razões depende do volume de dados copiados. Um punhado de registros vazado de um ambiente de testes causa o mesmo transtorno para a pessoa envolvida que uma base inteira, porque o dano está ligado à identidade de alguém, não à quantidade de linhas.
Dado real e dado sintético lado a lado
A tabela abaixo resume a diferença prática entre as duas escolhas. Ela não trata de qualidade técnica, e sim do que cada uma obriga você a administrar depois.
| Critério | Identidade real | Identidade sintética |
|---|---|---|
| Pertence a alguém | Sim | Não |
| Pode circular em repositório | Não | Sim |
| Serve para validar formato de campo | Sim | Sim |
| Serve para demonstrar a tela | Não deveria | Sim |
| Precisa de retenção e descarte | Sim | Não |
| Sobrevive à troca de equipe | Sim, e é isso o problema | Sim |
O ponto da última linha merece destaque: uma cópia de produção em homologação é invisível até virar incidente, porque ninguém lembra que ela foi feita. Um conjunto sintético, ao contrário, é explícito por natureza: se está ali, alguém o colocou ali com essa intenção.
Quando esse tipo de amostra é necessário?
Há quatro situações em que um registro fabricado resolve o problema inteiro, e todas elas são comuns:
- Homologação de formulários. Um campo de documento precisa aceitar formatos de vários países, e testar isso com dado real exigiria pedir documentos a pessoas.
- Demonstrações. Vender, ensinar ou apresentar um produto exige telas preenchidas. Uma demonstração que mostra o cadastro de um cliente verdadeiro é um vazamento, ainda que pequeno.
- Teste de carga. Popular um banco com muitos milhares de registros coerentes é inviável com dado real e trivial com dado gerado.
- Verificação de exibição. Nomes longos, caracteres não latinos, sobrenomes compostos e endereços de países diferentes quebram telas que ninguém pensou em testar.
Em todos os casos, o objetivo é exercitar o software, não as pessoas. É por isso que o registro precisa parecer plausível, e não ser verdadeiro.
Gerando os conjuntos no navegador
No gerador de identidade desta página, você escolhe o país ou a região, opcionalmente a divisão administrativa e o gênero, e recebe um registro completo com nome, data de nascimento, número de documento, endereço, telefone e perfil online. Os campos saem coerentes entre si: o telefone carrega o código do país escolhido, o documento segue a estrutura daquele país e a divisão administrativa pertence a ele.
O resultado pode ser copiado em bloco ou exportado, o que ajuda a montar uma massa de teste sem digitação manual. Se o seu cenário envolve outro tipo de dado, a mesma lógica vale para endereços e telefones, que também saem no formato do país selecionado.
Para quem desenvolve: anatomia de um registro
Uma identidade de teste quebra de duas maneiras previsíveis: campos faltando e campos que não combinam entre si. Antes de usar um conjunto em um caso automatizado, vale mapear o que a sua aplicação realmente consome.
Um registro típico se organiza em grupos: identificação (nome completo, data de nascimento, gênero), documento (tipo, número, país emissor), contato (telefone, correio eletrônico) e localização (endereço, cidade, divisão, código postal). Cada grupo tem dependências internas. A data de nascimento determina a idade exibida. O país determina o formato do documento e do telefone. O endereço tem que pertencer ao mesmo país do documento, ou o registro é inconsistente.
Duas decisões ajudam muito:
- Fixtures fixos para verificação. Quando um teste compara uma saída com um valor esperado, o registro precisa ser o mesmo em toda execução. Guarde uma amostra congelada e reutilize.
- Geração aleatória para exploração. Quando o teste pergunta se o sistema aceita qualquer entrada plausível, variar o registro a cada execução encontra defeitos que uma amostra fixa nunca mostraria.
Misturar as duas coisas é o erro mais comum: um teste de igualdade alimentado por dado aleatório falha uma vez por semana e ninguém entende por quê. Marque no próprio caso de teste se ele espera um registro estável ou uma variação, e o diagnóstico deixa de ser um mistério.
Próximos passos
Comece pelos campos que a sua aplicação realmente exibe e valida, e gere alguns registros no gerador de identidade para ver como o formato muda de país para país. Se você precisa decidir onde guardar essas amostras, o texto sobre dados de identidade em dados fixos de teste trata da organização do conjunto, e a página sobre consistência entre campos explica por que um registro bonito e incoerente é pior do que um registro feio.