Casos de teste de endereço de checkout: preenchimento automático, correções e recálculo de frete

A entrada de endereço tem vários caminhos

Cubra a entrada do teclado, preenchimento automático do navegador, colagem de várias linhas, sugestões e endereços salvos. Cada caminho deve produzir um contrato API, mantendo os detalhes do país e da unidade.

Um tempo limite de sugestão não deve bloquear uma entrada manual válida. Explique que o comprador pode continuar em vez de ficar preso em uma lista vazia.

Mantenha o comprador no controle das correções

Mostre os endereços inseridos e sugeridos lado a lado, destaque as alterações e permita o original. Nunca deixe cair silenciosamente o nome de um apartamento ou prédio.

Teste aceitar, reter, reabrir, tempo limite e uma sugestão faltando na linha 2.

Recalcular frete, impostos e métodos de entrega

Uma edição de país, região ou código postal pode invalidar métodos e alterar frete, impostos, limites e datas. Bloqueie o envio final até que a nova cotação chegue.

Edições rápidas criam cotações simultâneas. Aplique apenas o resultado correspondente à versão mais recente do endereço.

• Limpar métodos inválidos após mudança de país
• Atualizar frete e impostos juntos
• Ignorar respostas de citações obsoletas
• Preservar carrinho e endereço após falha

Faturamento e remessa precisam de cópias editáveis independentes

Da mesma forma que o envio pode criar uma cópia, mas os dois não devem compartilhar um objeto mutável. A edição do faturamento após desmarcar não deve alterar o frete.

Use a sandbox do provedor de pagamento e gatilhos documentados em vez de dados aleatórios para verificações de endereço de pagamento.

shippingAddress = structuredClone(selectedAddress);
billingAddress = sameAsShipping
  ? structuredClone(shippingAddress)
  : enteredBillingAddress;

Torne o envio final idempotente e tire um instantâneo do endereço

Cliques duplos, novas tentativas de tempo limite e navegação de retorno móvel podem repetir uma solicitação. Desative ações repetidas da interface do usuário e use uma chave de idempotência do lado do servidor.

Armazene o instantâneo do endereço confirmado e a versão da cotação no pedido, em vez de apenas fazer referência a uma entrada editável do catálogo de endereços.

A cobertura móvel deve incluir o teclado do software que oculta a ação principal, colocar em segundo plano e restaurar a página e retornar de uma autorização de pagamento externa. Ao retomar, consulte o pedido existente ou a solicitação idempotente antes de enviar outra operação de criação.

Audite um pedido cujo endereço mudou duas vezes durante a finalização da compra. Seu instantâneo deve conter a versão final confirmada, sua cotação de envio deve pertencer a essa versão e uma edição posterior no catálogo de endereços do comprador não deve reescrever o pedido histórico.

Teste também a falha ambígua: o navegador atinge o tempo limite após o envio, mas o servidor já criou o pedido. Uma nova tentativa com a mesma chave deve retornar o resultado original em vez de cobrar novamente ou reservar o inventário duas vezes. As ferramentas de suporte devem expor a chave da solicitação, a versão do endereço e o identificador do pedido sem expor o endereço completo nos logs de rotina. Isso torna a recuperação testável e, ao mesmo tempo, limita o acesso desnecessário a dados pessoais.

• Simule clique duplo, nova tentativa de tempo limite e devolução de pagamento
• Consultar o status idempotente após a restauração da página
• Combine o endereço do pedido e as versões da cotação
• Reabrir o histórico após editar o catálogo de endereços