CPF e CNPJ fictícios: o risco de colisão em massa de teste

Gerar um CPF ou CNPJ matematicamente válido resolve o problema mais óbvio de massa de teste: o número passa em qualquer validação de dígito verificador sem pertencer a ninguém, evitando o risco jurídico e técnico de reutilizar um documento real. Mas existe uma pergunta mais sutil, raramente feita, que só aparece quando a suíte de teste começa a gerar milhares de registros de uma vez: qual a chance de um desses números fictícios coincidir com o CPF ou CNPJ de uma pessoa ou empresa real que existe de fato? E, separadamente, qual a chance de dois registros gerados na mesma rodada colidirem entre si? As duas perguntas têm resposta calculável, e os números surpreendem quem nunca parou para fazer a conta.

O espaço de valores não é infinito

Um CPF tem 11 dígitos, mas só 9 são livres: os dois últimos são dígitos verificadores calculados a partir dos 9 primeiros pelo módulo 11, então cada raiz de 9 dígitos determina exatamente um CPF válido. Isso significa que o universo inteiro de CPFs matematicamente possíveis tem no máximo 1 bilhão de combinações (10 elevado a 9), e não os 100 bilhões que os 11 dígitos brutos sugerem à primeira vista. Como praticamente toda a população brasileira, mais de 200 milhões de pessoas, tem CPF, uma fração considerável dessas raízes já está em uso por alguém de verdade, embora a distribuição não seja uniforme (a raiz carrega a região fiscal no 9º dígito, então a densidade varia por região).

O CNPJ segue a mesma lógica com um espaço menor: a raiz (que identifica a empresa, antes da filial e dos dígitos verificadores) tem só 8 dígitos, um universo de até 100 milhões de combinações. Segundo o Mapa de Empresas do governo federal, o Brasil tem cerca de 28 milhões de CNPJs em situação cadastral ativa, e esse número não conta os que já foram baixados ou estão suspensos ao longo da história do cadastro, então a fração do espaço total já ocupada é ainda maior do que os 28 milhões sozinhos sugerem.

Colidir com um documento real: risco baixo, mas não zero

Isso não significa que gerar um CPF fictício tem 20% de chance de "acertar" o documento de alguém em cada tentativa: a raiz sorteada precisaria coincidir exatamente com a raiz daquela pessoa específica, e o espaço de 1 bilhão de combinações torna essa coincidência, para qualquer indivíduo, algo da ordem de 1 em várias centenas de milhões por sorteio. O ponto prático não é "isso vai acontecer com você", é que a probabilidade deixa de ser desprezível quando a escala cresce: gerar centenas de milhares de registros em um teste de carga eleva a chance agregada de que pelo menos um dos números fictícios coincida com a raiz de um CPF real de terceiro, mesmo sem nenhuma intenção de mirar em ninguém específico. Na prática isso raramente causa dano, porque o sistema sob teste não tem como saber que aquele número "pertence" a alguém fora do ambiente de teste, mas é uma possibilidade que vale entender antes de assumir que "fictício" é sinônimo de "impossível de colidir".

O risco que realmente importa: colisão entre os próprios registros gerados

A pergunta mais relevante para quem monta massa de teste em escala não é a colisão com um terceiro desconhecido, é a colisão dentro do próprio lote gerado, o clássico paradoxo do aniversário: a chance de duas pessoas em uma sala compartilharem a data de nascimento cresce muito mais rápido do que a intuição sugere, porque o que importa não é comparar cada uma contra um alvo fixo, é comparar todos os pares entre si. Aplicando a mesma matemática ao espaço de 1 bilhão de raízes de CPF, a probabilidade de pelo menos uma colisão interna ao gerar N registros aleatórios cresce assim:

O CNPJ colide muito mais cedo por ter um espaço 10 vezes menor: com apenas 10 mil registros gerados aleatoriamente, quase 4 em cada 10 lotes já vão conter pelo menos um par duplicado. Para quem usa esses dados como chave primária em um banco de teste, ou espera unicidade em um cenário de carga, ignorar esse número é receita para um teste que falha de forma intermitente e difícil de reproduzir, porque a colisão depende da sorte do sorteio daquela rodada específica.

O que fazer na prática

Para lotes pequenos, a chance de colisão é irrelevante: gerando os 100 registros de uma vez que os geradores de CPF e CNPJ deste site permitem por clique, a probabilidade fica na casa de 0,0005% para CPF e 0,005% para CNPJ, o que na prática nunca aparece. O cuidado começa a valer a pena quando o volume sai da interface e vai para um script (usando a exportação em JSON como fixture, por exemplo) gerando dezenas de milhares de registros em lote: nesse caso, vale manter um Set das raízes já geradas e descartar (ou regenerar) qualquer repetição, um ajuste de poucas linhas de código que elimina o problema por completo.

Vale ainda considerar, para fixtures pequenas e reutilizáveis entre execuções, usar deliberadamente números de teste já conhecidos e reservados pela comunidade, como o clássico 111.444.777-35: por ser amplamente reconhecido como dado de teste, reduz o risco de alguém confundir esse valor com um documento real ao encontrá-lo em um log, print de tela ou ticket de suporte, algo que um CPF aleatório recém-gerado não garante.