Um gerador de número de identidade existe porque número de documento não é texto livre. Cada país define o comprimento, os caracteres aceitos, a posição dos dígitos verificadores e, em muitos casos, uma regra que amarra o valor ao estado ou à região de emissão. Um campo que aceita qualquer sequência não valida nada, e um campo que valida errado recusa gente de verdade. Neste texto, comparamos formatos de meia dúzia de países, mostramos por que um exemplo com dígitos em sequência não serve para teste, explicamos por que o comprimento precisa vir da configuração e não do código e fechamos com os limites de uso em fluxos de verificação de identidade.
Por que cada país tem um formato diferente?
Um número de identidade é um identificador administrativo, e o desenho dele reflete a história de cada país. Alguns são puramente sequenciais, outros embutem data de nascimento, outros embutem região de emissão, e alguns combinam as três coisas em um só valor. Não existe padrão internacional que unifique esses formatos, e é por isso que uma regra única de validação sempre erra.
Nos Estados Unidos, o número de seguro social tem nove dígitos, escritos em três grupos, e a lógica de emissão original ligava os primeiros dígitos à região onde o número foi pedido. Faixas específicas nunca são emitidas, e existe uma lista de valores reservados para uso em exemplos e propaganda. Um validador que só confere a quantidade de dígitos aceita valores que o próprio órgão emissor nunca usa.
Na China, o documento de residente tem dezoito dígitos e carrega a data de nascimento em posições fixas, além de um código de região e de um dígito verificador calculado. No Brasil, o cadastro de pessoa física tem onze dígitos e dois verificadores calculados por uma regra própria. Na Turquia, o número de identidade tem onze dígitos, começa por um algarismo diferente de zero e termina em dois verificadores com regras distintas. Na Espanha, o documento nacional de identidade combina oito dígitos e uma letra, e o número de identificação de estrangeiro usa uma letra inicial diferente.
A conclusão para quem desenvolve é simples: o campo de documento de um cadastro internacional não é um campo, são vários, com regras distintas.
O que os dígitos verificadores protegem?
O dígito verificador existe para detectar erro de transcrição. Ele é calculado a partir dos demais dígitos por uma regra pública, e a chance de um erro simples passar é pequena. Isso protege contra digitação errada, não contra fraude, e é importante não confundir as duas coisas.
Em teste, o efeito é que um exemplo com dígitos em sequência, do tipo um dois três quatro cinco seis sete oito nove, não passa em nenhuma validação que calcule o verificador. Se o seu sistema rejeita esse valor e aceita outro calculado corretamente, a lógica está funcionando. Se ele aceita os dois, a validação provavelmente não existe, e o teste revelou uma lacuna real.
A recomendação prática é manter dois conjuntos. Um com valores de formato correto e verificadores válidos, para os casos em que o sistema deve aceitar. Outro, pequeno e explícito, com verificadores alterados e comprimentos errados, para os casos em que o sistema deve recusar. O valor do segundo conjunto é provar que a mensagem de erro aparece no lugar certo e não na tela de confirmação.
Por que o comprimento precisa vir da configuração?
Escrever o comprimento no código parece inofensivo e cobra caro depois. Um validador que exige nove dígitos para todo documento funciona enquanto o cadastro é doméstico e quebra no primeiro cliente estrangeiro. A correção posterior costuma ser feita com pressa, e o resultado é uma sequência de condições especiais espalhadas por vários arquivos.
A alternativa é tratar o formato como dado. Cada país tem uma definição, com comprimento, conjunto de caracteres, presença e posição de verificador e, quando aplicável, regras de prefixo. O validador consulta essa definição em vez de conhecer cada país. Fica mais fácil acrescentar um país novo, mais fácil testar e mais fácil explicar por que um valor foi recusado.
Essa decisão também ajuda no teste. Com as regras em configuração, dá para gerar casos de documento a partir da mesma fonte que o sistema usa para validar, e um erro de digitação na tabela aparece imediatamente em vez de virar um defeito silencioso. O resumo sobre comprimento do número de identidade por país reúne os comprimentos mais usados, e o texto sobre validação de identidade por país trata das regras de cálculo.
O documento precisa combinar com os outros campos?
Precisa, e essa é a parte que mais escapa. Um registro com documento de um país e endereço de outro é inconsistente, e um teste que usa esse registro exercita um caminho que não acontece na operação real. O mesmo vale para a data de nascimento, quando ela está embutida no número, e para o código de região, quando ele existe.
Há três verificações que valem a pena. A primeira é entre documento e país do registro. A segunda é entre a data embutida no documento e o campo de nascimento, quando o formato carrega essa informação. A terceira é entre o documento e o formato do telefone e do endereço, porque um registro completo sai coerente ou não sai.
No gerador de identidade desta página, o documento segue a estrutura do país escolhido e os campos vizinhos pertencem ao mesmo país, o que evita que a sua bateria acumule combinações impossíveis. Configurar isso à mão, campo por campo, é a origem mais comum de massa de teste incoerente.
Como testar um fluxo de verificação sem dado real?
A primeira decisão é usar dado sintético. Nenhum teste de cadastro precisa de documento de pessoa real, e usar um cria risco de privacidade sem melhorar a cobertura. Um valor gerado com formato correto exercita a mesma lógica de validação.
A segunda é separar o que o seu sistema faz do que um serviço externo faz. Se a sua verificação consulta uma base oficial, o teste automatizado deve usar um dublê de serviço, e não uma chamada real. Assim a bateria roda sempre e a dependência externa fica isolada em um teste de integração que roda quando faz sentido.
A terceira é cobrir as bordas de exibição. Documentos com letras, com espaços, com pontos e com hífen aparecem na prática, e o campo precisa aceitar, normalizar e mostrar de forma consistente. Nomes longos e caracteres não latinos também valem um caso, porque quebram telas que ninguém pensou em testar.
A quarta é tratar o fluxo de recusa. O que o sistema faz quando o documento não passa na validação? A mensagem diz o motivo ou apenas que houve erro? O usuário consegue corrigir sem perder o que já preencheu? Essas perguntas rendem mais defeito do que a validação em si.
Que cuidados de privacidade se aplicam aqui?
Documento de identidade é dado pessoal, e um ambiente de teste costuma ter controle de acesso mais frouxo do que a produção. Copiar uma base real para homologação é o erro mais comum, e o dano não depende do volume: um punhado de registros vazado causa o mesmo transtorno para a pessoa envolvida que uma base inteira.
Dado sintético resolve o problema pela raiz, porque não existe titular. Ele pode circular em repositório, ser publicado em exemplo de documentação e ser usado em mil execuções sem que ninguém seja afetado. O resumo sobre a relação entre a LGPD e dados de identidade para teste trata dessas obrigações com mais detalhe.
Vale também limitar o que o sistema guarda. Se o documento não é necessário depois da verificação, não deve ser retido. Um teste que confirma que o dado é descartado na hora certa é tão valioso quanto o teste que confirma que ele é aceito.
Como encaixar o gerador na rotina de teste?
Comece mapeando quais países o seu produto realmente atende. Para cada um, confirme o formato do documento e escreva um caso positivo e um negativo. Depois gere um conjunto de registros coerentes no gerador de identidade e congele uma parte dele no repositório para os testes que comparam saída com valor esperado.
Mantenha a outra parte como geração em tempo de execução, para os testes que perguntam se o sistema aceita qualquer entrada plausível. Marque no próprio caso de teste qual dos dois modos ele espera, e o diagnóstico de falha deixa de ser um mistério.
Por fim, revise a cada trimestre se algum país atendido mudou de regra. Formato de documento muda com menos frequência do que preço de produto, e muda o suficiente para que uma revisão semestral valha a pena.
Limites: dado sintético não é identidade
Os registros produzidos são dados sintéticos de formato correto, criados para exercitar software. Eles não correspondem a pessoas, não são aceitos por nenhuma verificação de identidade, não servem para abrir conta, contratar serviço ou passar por qualquer processo que exija uma pessoa real, e não devem ser apresentados como se fossem de alguém.
O uso pretendido é testar: validar máscara e comprimento, exercitar o cálculo do verificador no seu próprio código, verificar mensagens de erro, conferir a coerência entre campos e popular um ambiente de homologação. Nada além disso.