Um gerador de e-mail temporário resolve um problema pequeno e teimoso: o seu fluxo de cadastro envia uma mensagem de confirmação, e o teste automatizado precisa ler essa mensagem para continuar. Sem uma caixa descartável, o time acaba usando a conta pessoal de alguém, acumulando mensagens de teste na caixa de trabalho e, pior, criando uma dependência externa que quebra quando a pessoa sai da empresa. Neste texto, explicamos o que é uma caixa temporária, no que ela difere de um alias de encaminhamento e de um domínio catch-all, o que ela resolve em teste de verificação e código de uso único, por que muitos sites bloqueiam esses domínios e em que situações você não deve usá-la de forma alguma.
O que é uma caixa temporária, na prática?
Uma caixa temporária é um endereço que existe por um período curto, recebe mensagens normalmente e depois é descartado junto com o conteúdo. Do ponto de vista do servidor que envia a mensagem, ela é uma caixa comum: tem domínio, tem registro de correio e aceita entrega. Do ponto de vista de quem a criou, ela é um recurso efêmero, criado para um teste específico e abandonado depois.
O prazo de validade é a característica que define o resto do comportamento. Como a caixa some, não faz sentido guardá-la como ativo de longo prazo, e como ela é pública por natureza em muitos serviços, não faz sentido colocar nela qualquer informação sensível.
Em teste de software, isso é exatamente o que se quer. A mensagem de confirmação tem valor por poucos minutos, e depois disso ela é apenas histórico que ninguém vai consultar.
Caixa descartável, alias e catch-all são a mesma coisa?
Não são, e confundir os três leva a decisões ruins de arquitetura de teste. Um alias de encaminhamento é um endereço adicional que entrega na caixa principal de alguém. Ele é estável, tem dono e não desaparece. Serve para separar origens de mensagem, não para descartar conteúdo.
Um domínio catch-all é um domínio configurado para aceitar mensagens destinadas a qualquer endereço local, mesmo que a caixa específica não exista. Ele é a peça mais útil em automação, porque permite criar um endereço novo a cada execução sem configurar nada: o endereço muda, o domínio permanece o mesmo.
A caixa temporária pública é a terceira coisa. Ela é oferecida por um serviço de terceiros, tem domínio compartilhado com muitos outros usuários e costuma ter prazo curto. É a opção mais rápida para uma verificação manual e a menos adequada para uma suíte de testes que precisa rodar todos os dias. O texto sobre caixa catch-all para homologação detalha a diferença na prática, e o resumo sobre caixa descartável cobre o vocabulário do tema.
Que problema ela resolve no teste de cadastro?
O fluxo de verificação por correio tem várias etapas e cada uma delas pode quebrar. A mensagem precisa ser enviada, precisa chegar, precisa ter um link ou um código legível, o link precisa apontar para o ambiente certo e a confirmação precisa mudar o estado da conta. Um teste que cobre tudo isso de ponta a ponta precisa ler a mensagem recebida, e é aí que a caixa temporária entra.
O uso mais comum é o código de uso único. O teste dispara o pedido, espera a mensagem, extrai o código e o submete. Se a caixa for compartilhada com outros usuários, a extração precisa ser seletiva, porque podem existir várias mensagens no mesmo lugar.
O segundo uso é o link de confirmação. Aqui o cuidado é outro: o link costuma ter prazo de validade e apontar para um domínio específico. Um teste que abre o link no navegador errado verifica o ambiente errado sem perceber.
Há ainda casos menos óbvios, como reenvio de mensagem, mensagem duplicada, mudança de endereço depois do cadastro e recuperação de senha. Todos usam a mesma mecânica de leitura, e ter uma caixa controlada pelo time torna esses cenários testáveis de forma repetível. O resumo sobre testar o fluxo de verificação por e-mail organiza esses cenários em uma sequência.
Por que tantos sites recusam domínios descartáveis?
Serviços com cadastro aberto têm interesse em dificultar a criação de contas em massa, e domínios descartáveis conhecidos são a ferramenta mais usada para isso. A resposta da indústria foi montar listas de domínios e recusar cadastros que venham delas. Alguns serviços vão além e recusam qualquer domínio sem histórico, o que atinge também domínios novos e legítimos.
Para quem testa, o efeito é direto. Se a sua suíte usa um domínio público de caixa temporária para testar o cadastro de outro produto, o resultado depende de uma lista que você não controla e que muda sem aviso. O teste passa durante meses e falha em uma terça-feira aleatória, e a causa aparente é um erro de validação no seu próprio código.
Há também o risco de entrega. Domínios muito usados ganham reputação ruim, e provedores de correio podem atrasar ou descartar mensagens vindas deles. Em um teste que espera a mensagem chegar em segundos, a falha aparece como tempo esgotado e não como recusa explícita, o que torna o diagnóstico mais difícil. O texto sobre por que sites bloqueiam domínios descartáveis entra no detalhe dessa dinâmica.
Domínio próprio ou serviço público?
A decisão depende do que o teste precisa provar. Se a pergunta é se o sistema envia a mensagem com o conteúdo correto, um domínio próprio com catch-all é a resposta mais estável: o endereço é criado na hora, o domínio tem reputação controlada pelo time e o acesso à caixa é programático. A suíte deixa de depender de um terceiro e passa a depender de uma configuração que o próprio time mantém.
Se a pergunta é se o sistema recusa cadastros de domínios descartáveis, então a caixa pública é justamente o objeto de teste, e usá-la é a escolha certa. Nesse caso vale fixar uma lista própria de domínios de teste no repositório e rodar o cenário contra ela, em vez de depender de um serviço cuja lista muda.
Se o objetivo é apenas uma verificação manual rápida, durante uma investigação, a caixa pública é a opção mais barata, desde que ninguém coloque ali dado sensível e ninguém a use para receber algo importante. Em qualquer um dos três casos, o critério é o mesmo: escolher a ferramenta de acordo com a pergunta do teste, e não pela conveniência do momento.
Quando não se deve usar uma caixa temporária?
Há situações em que o uso é inadequado, e vale ser explícito. A primeira é qualquer conta real. Uma caixa temporária não deve servir para criar conta em serviço que a pessoa pretende usar, porque o endereço desaparece e a recuperação de acesso deixa de existir.
A segunda é qualquer dado de produção. Se a mensagem contém informação de cliente, ela não deve passar por uma caixa pública, que por definição tem acesso compartilhado e sem controle.
A terceira é qualquer situação com exigência de retenção. Processos que precisam comprovar envio, guardar histórico ou atender auditoria exigem armazenamento durável e com controle de acesso, e uma caixa que expira em minutos não atende a esse requisito.
A quarta é o uso para contornar limites de um serviço de terceiros. Isso não é teste, é abuso, e o efeito colateral é o domínio inteiro entrar em listas de bloqueio e prejudicar também quem o usa legitimamente.
Como ficam os anexos e o conteúdo das mensagens?
Testar correio não é só testar o endereço de destino. A mensagem tem assunto, remetente, corpo em duas versões, cabeçalhos e, muitas vezes, anexo. Cada uma dessas partes tem um modo de falha próprio, e uma caixa que descarta anexos ou trunca o corpo esconde o defeito em vez de revelá-lo.
Vale verificar se a caixa usada em teste preserva o corpo em texto simples e em marcação, porque muitos clientes exibem apenas uma das duas versões e o erro de formatação só aparece na outra. Verifique também se os cabeçalhos que interessam sobreviveram, como o endereço de resposta e a identificação da mensagem, já que a leitura seletiva por identificador depende do segundo.
Anexos merecem um caso próprio. Envie um arquivo pequeno, um arquivo no limite de tamanho e um arquivo acima do limite, e confira se o sistema trata o excesso com uma mensagem clara. Em fluxo de candidatura e de suporte, o anexo é parte do caso de uso e não um detalhe.
Vale ainda testar a codificação. Um assunto com acentuação e um corpo com caracteres não latinos exercitam a conversão de conjunto de caracteres, que é uma fonte clássica de texto embaralhado. Se a sua caixa de teste não preserva a codificação corretamente, você vai atribuir ao seu próprio código um defeito que está na ferramenta.
Como manter a caixa de teste saudável ao longo do tempo?
Uma caixa de teste acumula o que as execuções deixam para trás. Sem limpeza, ela cresce, a leitura fica lenta e a busca por identificador passa a varrer um histórico enorme. Em algum momento alguém apaga tudo, o que também é ruim, porque perde a evidência de um defeito que ainda estava em investigação.
A rotina que funciona tem três passos. Primeiro, cada mensagem recebida é vinculada ao identificador da execução que a provocou. Segundo, uma limpeza automática apaga o que é mais antigo do que alguns dias. Terceiro, quando um defeito é confirmado, a mensagem relevante é exportada para o relatório do defeito antes da limpeza.
Vale também monitorar o próprio domínio de teste. Se as mensagens começarem a ser recusadas, é sinal de que ele entrou em alguma lista de bloqueio, e descobrir isso antes da suíte falhar economiza tempo de investigação. Um teste simples que envia para si mesmo e confirma a chegada resolve o monitoramento.
Como encaixar isso na sua suíte
A configuração mais confiável para automação tem três partes. Um domínio controlado pelo time, com catch-all habilitado. Uma convenção de endereço que inclua a identificação da execução, para que a leitura da mensagem seja seletiva e não pegue o conteúdo de outro teste rodando em paralelo. E um passo de limpeza que apague o que foi recebido depois da execução, para que o ambiente não acumule mensagem de teste.
Vale também prever um caminho alternativo para quando o provedor de correio demorar. Um teste que espera para sempre é pior do que um teste que falha com mensagem clara, então defina um tempo limite curto e registre o motivo da espera no relatório.
Para quem precisa cobrir o envio de mensagens transacionais como um todo, o gerador de e-mail temporário é o ponto de partida para obter endereços de teste, e a lista de verificação de e-mail transacional cobre os casos que costumam ficar de fora.
Limites de uso
Os endereços e caixas produzidos para teste são recursos sintéticos, destinados a exercitar o seu próprio software. Eles não devem ser usados para criar contas reais, para se passar por outra pessoa, para contornar limites de serviços de terceiros ou para receber informação de produção. O uso pretendido é verificar se o seu sistema envia, formata, endereça e valida mensagens corretamente em um ambiente controlado, com dados que não pertencem a ninguém.