Dados de teste de endereço sintético: criando fixtures reproduzíveis

Fixtures fixos e aleatórios têm funções diferentes

Os fixtures fixos são adequados para snapshots, contratos e migrações. A geração aleatória expande as combinações, mas sem uma semente cria falhas que ninguém pode reproduzir.

Mantenha um pequeno conjunto de regressão revisado e um gerador que aceite semente, país e cenário. Promova falhas úteis em fixtures fixos.

Reconhecível sem quebrar o formato

Use domínios reservados como example.com, adicione dataPurpose e fixtureId e registre fixtureId em vez de um endereço completo. Mantenha o formato postal realista ao testar um analisador.

Nunca copie um cliente e substitua apenas o nome. Outros campos ainda podem identificar uma pessoa ou enviar notificações.

{
  "fixtureId": "ca-boundary-003",
  "dataPurpose": "synthetic-test",
  "seed": 7319,
  "countryCode": "CA",
  "email": "qa-7319@example.com"
}

Aleatório não significa inconsistente

Defina invariantes: o formato do país concorda, os campos regionais vêm de uma tupla, os códigos postais permanecem como texto e as linhas opcionais permanecem vazias em vez de N/A. Os testes de propriedade podem verificar isso em muitas sementes.

Um fixture inválido pode quebrar uma invariante, mas deve declarar expectedError para que ninguém o trate como dado normal.

• Cada semente é reproduzível
• Tuplas regionais normais permanecem consistentes
• Equipamentos inválidos quebram uma regra nomeada
• A saída registra a versão dos dados de referência

Evite efeitos colaterais de produção

Teste e-mail, SMS, impressão, processamento e integrações de pagamento por meio de sandboxes ou blocos de saída. Escrever Teste em um endereço não impede uma chamada logística real.

O CI deve verificar o ambiente e os tipos de credenciais e rejeitar registros de testes sintéticos que entram nas filas de produção.

Transforme falhas em ativos de regressão

Mantenha o registro, a semente, a versão dos dados e a asserção com falhas mínimas. Desduplicar periodicamente, mas não regenerar equipamentos estáveis ​​apenas para fazê-los parecer novos.

Dê a cada fixture fixo um proprietário, cenário, resultado esperado, motivo de criação e data de revisão. Um grande arquivo JSON que não explica o comportamento que protege rapidamente se torna uma pilha em que ninguém confia e ninguém ousa excluir. Durante a revisão, identifique coberturas duplicadas e regras às quais o produto não se aplica mais.

Não tire instantâneos da IU de saída aleatória irrestrita. Use um registro fixo explícito para instantâneos e deixe testes aleatórios afirmarem propriedades e invariantes. Essa divisão evita a mudança de instantâneos sem sentido sempre que uma rua gerada muda, preservando ao mesmo tempo uma ampla cobertura exploratória.

Trate uma atualização de dados de referência como uma alteração de dependência. Execute o conjunto inicial antigo no novo instantâneo, revise as diferenças intencionais e retenha ambas as versões por tempo suficiente para explicar por que um registro anteriormente reproduzível foi alterado.

Acompanhe a cobertura por cenário, não pelo número bruto de linhas geradas. Dez mil endereços comuns não substituem um fixture deliberado para uma unidade ausente, código postal com zero inicial, nome de edifício muito longo ou região não suportada. Uma matriz de cobertura compacta permite que os revisores vejam qual regra cada aparelho exerce e onde o gerador ainda possui pontos cegos.

• Atribuir um proprietário e comportamento protegido
• Revise casos duplicados e obsoletos
• Use fixtures fixos para instantâneos e fixtures aleatórios para propriedades
• Atualizações de dados de referência de versão explicitamente