Artigo Build·Desenvolvimento·13 min de leitura de leitura

CPF para Testes em Desenvolvimento (2026): Como Usar, LGPD e Boas Práticas

Usar CPF real em desenvolvimento é um dos erros mais comuns — e caros — em equipes brasileiras. Este guia mostra por que isso viola a LGPD, como gerar documentos fictícios em qualquer linguagem, estratégias para isolar teste de produção e ferramentas que já resolvem o problema.

Por Vitor Morais

Fundador do MochaLabz · publicado em 20 de abril de 2026

🪪

Gere CPFs em lote

Formatação, quantidade e download em CSV — tudo no navegador, sem cadastro.

Usar gerador →

Todo dev que trabalha com sistemas brasileiros eventualmente precisa de CPFs em ambiente de teste: popular banco de staging, validar formulário, executar teste automatizado, demonstrar produto pra cliente. A tentação é sempre a mesma: pegar “um CPF válido qualquer” — o seu, de um colega, de alguma planilha antiga. Esse atalho é um dos erros mais caros em equipes brasileiras modernas.

Este guia cobre por que nunca se deve usar CPF real em teste (LGPD + pragmática), como gerar fictícios em qualquer linguagem, como isolar dados de teste de produção e as ferramentas que já resolvem o problema em cada stack.

Por que CPF real em teste é grave

1. LGPD trata como dado pessoal

A Lei Geral de Proteção de Dados (Lei 13.709/2018) define CPF como dado pessoal. O uso em qualquer contexto exige: base legal documentada, finalidade legítima, medidas técnicas de proteção. Ambiente de teste costuma violar os três ao mesmo tempo:

Dado foi coletado para uso em produção, não teste — desvio de finalidade.
Banco de staging tem menos segurança que produção — medida técnica insuficiente.
Consentimento do titular não cobre “seu CPF em banco de testes da dev”.

Sanções: até 2% do faturamento do grupo econômico no Brasil, limitada a R$ 50 milhões por infração. ANPD já aplicou multas reais desde 2023.

2. Vazamento de staging vira vazamento público

Históricos reais: empresas tiveram bancos de staging expostos acidentalmente (credenciais commitadas no GitHub, servidor sem firewall, backup público). Todos os CPFs ali ficaram expostos. Se fossem fictícios, zero dano. Sendo reais, notificação aos titulares + comunicado à ANPD + possíveis ações individuais.

3. CPF de teste vira CPF real em produção

Cenário clássico: dev usa próprio CPF em ambiente de dev → sistema gera e-mail automático de “boas-vindas” → vai para lista de marketing → eventualmente recebe cobrança real no e-mail principal. Ou, pior, entra em fluxo de auditoria fiscal simulado e aparece em relatório como “cliente” inexistente.

Atenção

A regra mais importante deste artigo: nunca use seu próprio CPF em teste. Nunca. Uma linha simples de código (ou uma ferramenta com um clique) gera um CPF fictício válido que substitui seu real sem perda. A diferença de esforço é mínima; a diferença de risco é imensa.

O que é CPF fictício válido

CPF fictício é um número que passa na validação do módulo 11 (algoritmo dos dígitos verificadores) mas não foi emitido pela Receita Federal. Matematicamente indistinguível de um real para qualquer validador de sistema, mas não associado a nenhum cidadão.

O algoritmo é determinístico:

Gera 9 dígitos aleatórios (com regra: não podem ser todos iguais).
Calcula o 1º verificador via módulo 11 com pesos [10, 9, 8, 7, 6, 5, 4, 3, 2].
Calcula o 2º verificador com pesos [11, 10, 9, 8, 7, 6, 5, 4, 3, 2].
Junta em 11 dígitos.

Implementações por linguagem

JavaScript / TypeScript

export function gerarCPF(options: { formatado?: boolean } = {}): string {
  const nine = Array.from({ length: 9 }, () => Math.floor(Math.random() * 10));

  let sum = 0;
  for (let i = 0; i < 9; i++) sum += nine[i] * (10 - i);
  let d1 = 11 - (sum % 11);
  if (d1 >= 10) d1 = 0;

  sum = 0;
  const ten = [...nine, d1];
  for (let i = 0; i < 10; i++) sum += ten[i] * (11 - i);
  let d2 = 11 - (sum % 11);
  if (d2 >= 10) d2 = 0;

  const raw = [...ten, d2].join("");
  if (!options.formatado) return raw;
  return `${raw.slice(0, 3)}.${raw.slice(3, 6)}.${raw.slice(6, 9)}-${raw.slice(9)}`;
}

Python

import random

def gerar_cpf(formatado=False):
    nine = [random.randint(0, 9) for _ in range(9)]

    total = sum(d * (10 - i) for i, d in enumerate(nine))
    d1 = 11 - (total % 11)
    if d1 >= 10: d1 = 0

    ten = nine + [d1]
    total = sum(d * (11 - i) for i, d in enumerate(ten))
    d2 = 11 - (total % 11)
    if d2 >= 10: d2 = 0

    raw = "".join(map(str, ten + [d2]))
    if not formatado:
        return raw
    return f"{raw[:3]}.{raw[3:6]}.{raw[6:9]}-{raw[9:]}"

# Ou usando Faker (padrão em testes)
# pip install faker
from faker import Faker
fake = Faker("pt_BR")
fake.cpf()  # "123.456.789-01"

Ruby

require "faker"

Faker::Config.locale = "pt-BR"
Faker::CPF.number             # "14339725095"
Faker::CPF.number(formatted: true)  # "143.397.250-95"

Java

// Com javafaker
import com.github.javafaker.Faker;
import java.util.Locale;

Faker faker = new Faker(new Locale("pt-BR"));
String cpf = faker.cpf().valid();  // "143.397.250-95"

// Ou implementação custom:
public static String gerarCPF() {
    int[] nine = new int[9];
    for (int i = 0; i < 9; i++) nine[i] = (int) (Math.random() * 10);

    int sum = 0;
    for (int i = 0; i < 9; i++) sum += nine[i] * (10 - i);
    int d1 = 11 - (sum % 11);
    if (d1 >= 10) d1 = 0;

    int[] ten = Arrays.copyOf(nine, 10);
    ten[9] = d1;
    sum = 0;
    for (int i = 0; i < 10; i++) sum += ten[i] * (11 - i);
    int d2 = 11 - (sum % 11);
    if (d2 >= 10) d2 = 0;

    StringBuilder sb = new StringBuilder();
    for (int d : ten) sb.append(d);
    sb.append(d2);
    return sb.toString();
}

Go

package main

import (
    "fmt"
    "math/rand"
    "strings"
)

func gerarCPF() string {
    nine := make([]int, 9)
    for i := range nine {
        nine[i] = rand.Intn(10)
    }

    sum := 0
    for i := 0; i < 9; i++ {
        sum += nine[i] * (10 - i)
    }
    d1 := 11 - (sum % 11)
    if d1 >= 10 {
        d1 = 0
    }

    ten := append(nine, d1)
    sum = 0
    for i := 0; i < 10; i++ {
        sum += ten[i] * (11 - i)
    }
    d2 := 11 - (sum % 11)
    if d2 >= 10 {
        d2 = 0
    }

    var b strings.Builder
    for _, d := range append(ten, d2) {
        b.WriteString(fmt.Sprintf("%d", d))
    }
    return b.String()
}

Bibliotecas recomendadas por ecossistema

Bibliotecas para gerar CPF em ambientes de teste
Critério	Linguagem / pacote	Como usar
@faker-js/faker	Node/TS	faker.br.cpf()
cpf-cnpj-validator	Node/TS	cpf.generate({ formatted: true })
brazilian-values	Node/TS	cpf.generate()
faker (Python)	Python	Faker('pt_BR').cpf()
faker (Ruby)	Ruby	Faker::CPF.number
javafaker	Java	new Faker(pt-BR).cpf().valid()
FakerPHP	PHP	Factory::create('pt_BR')->cpf()
brdoc	Go	brdoc.NewCPF()

Isolando CPF de teste de CPF real

Mesmo com CPFs fictícios, é importante manter segregação entre ambientes. Cinco práticas comuns:

1. Ambientes separados

Dev, staging e prod em bancos diferentes. Nunca rode seed de teste em banco de prod. Parece óbvio, mas é a violação mais comum em startups pequenas.

2. Flag is_test na tabela

CREATE TABLE users (
    id         SERIAL PRIMARY KEY,
    cpf        VARCHAR(11) NOT NULL,
    nome       VARCHAR(255),
    is_test    BOOLEAN NOT NULL DEFAULT FALSE,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Consultas em prod filtram por padrão
SELECT * FROM users WHERE is_test = FALSE;

-- Report financeiro nunca conta registros de teste
SELECT SUM(valor) FROM pedidos p
JOIN users u ON u.id = p.user_id
WHERE u.is_test = FALSE;

3. Faixa numérica reservada

Reserve prefixo (ex: CPFs iniciando com “999” ou “000”) só para teste. Qualquer código ao processar detecta e marca apropriadamente. Útil em sistemas que não têm flag is_test.

4. Limpeza periódica

Em staging persistente, agende job semanal que limpa registros de teste. Mantém o banco limpo e reduz risco de confusão entre dados.

5. Conventions de seed

Seeders e factories em frameworks (Rails, Django, Laravel) devem sempre marcar registros como teste. Exemplo Rails:

# db/seeds.rb
return if Rails.env.production?

100.times do
  User.create!(
    cpf: Faker::CPF.number,
    nome: Faker::Name.name,
    is_test: true,
  )
end

Contexto

O return if Rails.env.production? é pequeno mas salva vidas (e multas). Funciona como “circuit breaker”: mesmo se alguém rodar rake db:seed no servidor de produção por engano, o seeder vai no-op.

Uso em testes automatizados

Com Jest/Vitest (Node), Pytest (Python) ou RSpec (Ruby), o padrão é gerar CPF em cada teste:

// Vitest
import { gerarCPF } from "./gerar-cpf";
import { validarCPF } from "./validar-cpf";

describe("validação de cadastro", () => {
  it("aceita CPF válido", () => {
    const cpf = gerarCPF();
    const result = cadastrarUsuario({ cpf, nome: "Teste" });
    expect(result.success).toBe(true);
  });

  it("rejeita CPF já cadastrado", () => {
    const cpf = gerarCPF();
    cadastrarUsuario({ cpf, nome: "Teste" });
    const result = cadastrarUsuario({ cpf, nome: "Outro" });
    expect(result.success).toBe(false);
  });
});

Seed reproduzível com faker

Para CI que deve gerar os mesmos CPFs a cada execução (reprodutibilidade de bug), passe uma seed fixa:

import { faker } from "@faker-js/faker";

// No início dos testes
faker.seed(42);

// Agora cada chamada produz o mesmo resultado entre execuções
faker.br.cpf(); // sempre "123.456.789-00" (exemplo)
faker.br.cpf(); // sempre "987.654.321-00"

Dica

Para debug de testes flaky que falham só “quando o CPF específico aparece”, usar seed fixo é ouro — você recria o cenário exato localmente.

Uso em API mock e documentação

Swagger, Postman, OpenAPI, ReadMe.io — todos aceitam exemplos de dados. Ofereça sempre CPFs fictícios ou genéricos:

# OpenAPI / Swagger
components:
  schemas:
    User:
      type: object
      properties:
        cpf:
          type: string
          pattern: "^\\d{11}$"
          example: "12345678909"  # CPF fictício válido
        nome:
          type: string
          example: "João da Silva"

Armadilhas comuns

Uso de CPFs “conhecidos”: 00000000000 a 99999999999 passam no módulo 11 mas não são usados pela Receita. Descarte explicitamente essas sequências.
Logs com CPF completo: mesmo fictício, não polua logs. Use masking (123.***.***-01) para consistência.
Compartilhar CSV de CPFs de teste: esses arquivos parecem produção em pastas compartilhadas. Nomeie com _TESTE_ visível.
Expor gerador em API pública: alguém pode usar para cadastros em massa. Restrinja ao ambiente de dev.
Gerar sem validar antes de inserir: bug no gerador passa CPF inválido para o banco. Sempre valide no insert.
Misturar gerados com reais no mesmo dump de export: é como enviar arquivo contaminado — difícil separar depois.

Ferramenta pronta para demos e seed rápido

Para uso manual (QA, demonstração, seed ad-hoc), um gerador web com configuração de quantidade e formato é mais rápido que abrir um REPL. O gerador interno do MochaLabz cria CPFs em lote, com opção de formato, exporta CSV e não envia nada pra servidor — 100% client-side.

CPF em uma frase

CPF real em ambiente de teste é bomba relógio: viola LGPD, expõe pessoas e aumenta superfície de vazamento. Gerar fictício leva 20 linhas de código (ou um clique em gerador) e elimina o risco. Não há justificativa boa para usar real — a diferença de esforço é nula, a diferença de risco é enorme.

Perguntas frequentes

Por que não usar CPFs reais em testes?+

Três motivos críticos. (1) LGPD: CPF é dado pessoal; testes com real violam base legal e podem gerar multa de até 2% do faturamento. (2) Vazamento: ambientes de teste costumam ter segurança menor; um banco de staging exposto vaza dados reais. (3) Confusão: CPFs reais em teste acabam em relatórios, e-mails automáticos, indexação — com consequências para pessoas reais. A regra é simples e universal: nunca.

CPF gerado por algoritmo é legal?+

Sim, quando usado exclusivamente em ambiente de teste e identificação clara. O CPF matematicamente válido (passa no módulo 11) não é, por si, dado pessoal — vira dado pessoal quando associado a uma pessoa natural identificável. Gerar dígitos aleatórios para popular banco de testes é pratica aceita globalmente e não gera problema jurídico, desde que o documento não seja usado em transação real.

Como gerar muitos CPFs únicos para testes de volume?+

Use função que aplica o algoritmo do módulo 11 e armazene em Set para garantir unicidade. Para 10 mil CPFs, um loop simples resolve em milissegundos. Para 1 milhão, o Set ainda é barato em memória (~30 MB) e garante zero colisão. Em teste de carga, pré-gere os CPFs em arquivo e carregue na memória para evitar CPU gasto com geração durante o teste.

Qual biblioteca Node.js para gerar CPF fictício?+

Três opções populares: (1) @faker-js/faker com locale pt_BR via faker.br.cpf() — a mais usada em testes automatizados. (2) cpf-cnpj-validator — foca em validação mas inclui generate(). (3) brazilian-values — pacote completo com CPF, CNPJ, telefone, CEP e mais. Para projetos pequenos, implementar o algoritmo (20 linhas) elimina dependência. Em projetos grandes, faker-js é padrão da indústria.

Como isolar CPFs de teste de CPFs de produção?+

Cinco práticas. (1) Ambiente separado: staging e prod têm bancos diferentes. (2) Flag is_test: coluna booleana que identifica registros de teste mesmo em prod. (3) Prefixo visual: CPFs de teste começam com 000 ou 999. (4) Range específico: reserve uma faixa numérica. (5) Soft delete periódico: limpe CPFs de teste a cada 30 dias em staging. Sem isso, CPF de teste eventualmente migra para relatório real.

CPF em mock API deve ser real ou fictício?+

Sempre fictício. Documentação pública de API, Postman collections, Swagger, diagramas de integração — todos expõem exemplos. Usar CPF real vira vazamento na cara. Prefira documentos claramente inválidos (000.000.000-00 em documentação) ou a faixa fictícia gerada. O Postman oferece variáveis dinâmicas ({{$randomCommonNumber}}) que casa bem com geradores locais.

Quais ferramentas existem por linguagem?+

Python: Faker (faker.pt_BR.cpf()). Ruby: gem 'faker' com Faker::CPF.number. Java: javafaker com Faker.instance().idNumber().ssnValid() + fake-name-generator; ou cpfcnpj-util. PHP: fzaninotto/faker (descontinuado; migre para FakerPHP/Faker). Go: github.com/paemuri/brdoc. Rust: fake-rs com generator customizado. Todas geram via algoritmo do módulo 11, zero risco de colidir com real.

É possível gerar CPF 'anônimo' mas associável a teste?+

Sim, via hash determinístico. Combine um seed controlado (ex: ID do usuário de teste) com função de geração: cada usuário 42 sempre recebe o mesmo CPF fictício. Isso permite testes reproduzíveis (mesmo CPF a cada execução) sem que seja um CPF real. Bibliotecas como faker aceitam seed: faker.seed(42). Ideal para debug e CI que precisa deterministicidade.

#cpf#testes#dev#lgpd#faker#staging#seed#mocking#ci#brasil