Gerador de Endereços e CEP Brasileiro

Endereços fictícios com coerência geográfica por estado. Valide formulários de checkout, APIs de frete e integrações com Correios sem expor dados reais.

Compatível com LGPD Coerência Geográfica

Geradores por cidade — Otimizados para testes localizados

Endereços fictícios: o campo mais complexo do e-commerce

Um guia técnico completo para testar formulários de entrega no Brasil.

Do ponto de vista de QA, o campo de endereço é o mais perigoso de testar inadequadamente. Ele envolve múltiplos campos interdependentes (logradouro, número, complemento, bairro, cidade, estado, CEP), regras de negócio complexas (zonas de entrega, cálculo de frete por região), integração com APIs externas (Correios, Google Maps) e restrições fiscais (ICMS por estado). Uma string genérica como "Rua Teste, 1" não vai descobrir nem 10% dos bugs reais.

A estrutura de um endereço brasileiro

Um endereço brasileiro completo para um sistema de e-commerce precisa de pelo menos 6 campos funcionando em harmonia:

CampoExemploO que testar
LogradouroRua das FloresTipo: Rua / Av / Travessa / Alameda
Número1247Sem número (s/n), número muito grande (99999)
ComplementoApto 42, Bloco BCampo optional — null não deve quebrar
BairroPinheirosBairros com acentos e nomes compostos
CEP05422-030Com e sem hífen, CEP inexistente, CEP de outro estado
Cidade + UFSão Paulo, SPCoerência: cidade ≠ estado do CEP

Testando zonas de entrega e cálculo de frete

Um dos maiores desafios de QA em e-commerces brasileiros é garantir que as regras de frete funcionam corretamente para diferentes regiões. O Brasil tem uma disparidade enorme de frete entre capitais e interior, entre Sul+Sudeste e Norte+Nordeste. Um bug de cálculo de frete pode custar caro — literalmente.

Teste de capital vs. interior

Gere um endereço de São Paulo (capital) e um de interior (Sorocaba, SP) e verifique se o frete e prazo diferenciam corretamente.

Teste de zona de restrição

Gere endereços de AC, RR, AM — estados de acesso difícil. Verifique se o sistema rejeita ou oferece opções alternativas adequadas.

Teste de cálculo de ICMS

CEPs de RS, SP e AM têm alíquotas de ICMS diferentes para e-commerce. Confirme que o imposto no pedido muda conforme o estado de destino.

Teste de formato de CEP

CEP com hífen '01310-100' e sem hífen '01310100' devem ambos funcionar. Teste que a sanitização ocorre antes da consulta à API dos Correios.

Mockando a API ViaCEP no Cypress

Em vez de deixar seus testes E2E dependerem de uma API externa instável, intercepte a chamada e retorne nosso payload. Isso torna seus testes determinísticos e 10x mais rápidos:

// cypress/e2e/checkout.cy.ts

cy.intercept("GET", "https://viacep.com.br/ws/*/json/", {
  statusCode: 200,
  body: {
    cep: "04538-133",
    logradouro: "Avenida Brigadeiro Faria Lima",
    bairro: "Itaim Bibi",
    localidade: "São Paulo",
    uf: "SP",
    ibge: "3550308"
  }
}).as("viaCep");

cy.get("[data-testid='cep-input']").type("04538133");
cy.wait("@viaCep");
cy.get("[data-testid='cidade']").should("have.value", "São Paulo");

Dica de Senior QA

Sempre que possível, crie dois cenários: um com intercept (para o happy path determinístico) e um sem intercept (para o teste de integração real que roda apenas no CI com acesso à internet). Você terá velocidade nos testes locais e garantia de integração real no pipeline.

Perguntas Frequentes — Endereços para QA

Os CEPs gerados funcionam na API dos Correios (ViaCEP)?

Os CEPs gerados são sintéticos — eles seguem o padrão numérico por estado (ex: CEPs de SP começam com dígitos na faixa de 01000 a 19999), mas não correspondem a endereços físicos reais. Para testes que dependem da API ViaCEP, a melhor prática é interceptar a requisição no Cypress (cy.intercept) ou Playwright (page.route) e retornar nosso payload como resposta mockada — isso garante que seus testes não dependem de serviços externos.

Como posso gerar endereços de um estado específico?

No gerador acima, selecione o estado desejado no filtro lateral antes de clicar em GERAR. A engine automaticamente vincula a cidade e o CEP ao estado selecionado, garantindo coerência geográfica. Para gerar centenas de endereços de um estado específico via API, envie o parâmetro 'estado': 'SP' no body do POST a /api/generate.

O que é 'consistência geográfica' e por que ela importa nos testes?

Consistência geográfica significa que a cidade, o estado e o CEP gerados fazem sentido juntos — São Paulo (SP) nunca aparece com o CEP de Salvador (BA). Isso importa porque sistemas de logística, calcúlo de ICMS e restrições de entrega usam a combinação de CEP + Estado para tomar decisões. Dados inconsistentes causam falsos positivos nos testes e mascaram bugs reais.

Como testar zonas de entrega e restrições logísticas?

Gere endereços dos estados que você quer testar, use-of como input no formulário de checkout simulado, e verifique se o sistema responde corretamente (permite ou nega entrega, calcula frete corretamente, mostra prazo correto). Para sistemas que só entregam em SP, teste com endereços de SP (aprovado) e de MA (negado) e certifique que ambos os casos têm o comportamento esperado.

Posso usar esses endereços em formulários reais de sites?

Não. Os endereços são estritamente para testes em ambientes de desenvolvimento, homologação e QA. Usar dados fictícios em formulários reais para completar compras, criar contas ou obter vantagens configura falsidade ideológica. Use exclusivamente em ambientes controlados de desenvolvimento.

Como combinar o endereço gerado com CPF e Nome para fixtures completas?

Use nossa ferramenta de Perfil Completo na página inicial — ela gera nome, CPF, RG, endereço e telefone em um único payload JSON coerente. Se prefere a API, chame POST /api/generate com o estado desejado e o retorno inclui todos os campos de identidade já vinculados geograficamente.

Complete sua base de dados de teste

Endereço é só o começo. Monte fixtures completas com identidade, documentos e contato.