Por que você não deve usar dados reais em testes
Usar um CPF real (mesmo que seja o seu) em ambiente de desenvolvimento é uma prática arriscada. Esses dados acabam em logs, dumps de banco de dados de dev, screenshots de bug reports e repositórios Git. A LGPD (Lei Geral de Proteção de Dados) trata isso como vazamento — mesmo que acidental.
A solução é gerar dados sintéticos que parecem reais, passam nas validações, mas não correspondem a nenhuma pessoa ou empresa real.
Tokens disponíveis no httpdrop
TokenExemplo de saídaUso
{{faker.cpf}}123.456.789-09CPF com dígitos válidos{{faker.cnpj}}12.345.678/0001-95CNPJ com dígitos válidos{{faker.name}}Ana Carolina RibeiroNome completo BR{{faker.email}}ana.ribeiro@email.comEmail fictício{{faker.phone}}(11) 99999-9999Telefone celular BR{{faker.address}}Rua das Flores, 42, São PauloEndereço completo{{faker.cep}}01310-100CEP no formato BR{{faker.price}}R$ 249,90Preço em BRL{{faker.uuid}}a3f8c1d2-...UUID v4{{faker.date}}2025-03-15Data aleatóriaUsando em Mock Rules
Mock Rule — GET /api/clientes/:id
{
"id": "{{faker.uuid}}",
"nome": "{{faker.name}}",
"cpf": "{{faker.cpf}}",
"email": "{{faker.email}}",
"telefone": "{{faker.phone}}",
"endereco": {
"logradouro": "{{faker.address}}",
"cep": "{{faker.cep}}"
},
"criado_em": "{{faker.datetime}}"
}
Casos de uso
Healthtech — Simule pacientes com nome, CPF, data de nascimento e histórico de consultas sem comprometer dados de nenhum paciente real.
Fintech — Teste fluxos de KYC com documentos (CPF, CNPJ), dados bancários e endereços 100% fictícios mas estruturalmente válidos.
E-commerce — Popule catálogos, pedidos e cadastros de clientes para demonstrações sem precisar de um banco de dados real.
CPF e CNPJ válidos: Os tokens
{{faker.cpf}} e {{faker.cnpj}} geram números que passam na validação do dígito verificador — suas funções de validação de formulário funcionam normalmente.