Um fluxo de cadastro e de recuperação de acesso não pode ser considerado validado enquanto não for executado com um e-mail real, com um código ou link reais — um mock no lugar do e-mail testa apenas o formulário, e não a cadeia de entrega, a leitura do código e o clique no link. Para isso, o testador não precisa de uma única caixa universal, e sim de endereços escolhidos para cada cenário e cada site. Vamos ver por que isso é necessário, por que o e-mail pessoal e o de trabalho não servem aqui, como escolher entre um endereço avulso e o aluguel, e o que vale registrar na documentação de testes.
Por que o testador precisa de endereços de e-mail separados
Um fluxo de cadastro de ponta a ponta não se resume a preencher o formulário: o site precisa enviar o e-mail, o testador precisa recebê-lo, extrair o código ou clicar no link e concluir a cadeia entrando na conta. Um mock que simplesmente grava um código fixo no banco de dados ignora tudo o que acontece entre o envio do e-mail e o recebimento — o atraso na entrega, o formato do e-mail de cada site, o comportamento ao abrir o link a partir de outro cliente de e-mail. Só é possível descobrir que a entrega real está falhando — o e-mail cai no spam, demora horas, chega com o link cortado — em um endereço de verdade, que realmente recebe mensagens.
Por que o e-mail pessoal e o corporativo não servem para isso
Usar a caixa pessoal para cadastros de teste parece uma solução rápida, mas ela se enche de e-mails de dezenas de contas de teste e dificulta encontrar depois as mensagens importantes da correspondência pessoal. O e-mail corporativo traz um risco de outro tipo: uma conta de teste cadastrada com um endereço de trabalho pode acabar envolvida em processos reais da empresa — entrar em uma lista de envio, ganhar acesso a integrações configuradas por domínio. Um endereço de teste separado elimina os dois riscos de uma vez: ele existe para uma única tarefa e não se mistura nem com a correspondência pessoal nem com os dados reais da empresa.
Ativação avulsa ou aluguel — o que escolher para o cenário
A escolha depende de quantos e-mails são esperados no cenário. Se o teste verifica exatamente uma etapa — cadastro e confirmação com um único e-mail — a ativação avulsa serve: uma caixa temporária para um site específico, que vale por 20 minutos e é encerrada por timeout, com reembolso automático se o e-mail não chegar. Se o cenário for mais complexo e exigir e-mails repetidos para o mesmo endereço — por exemplo, cadastro, depois recuperação de senha, depois novo login com confirmação por e-mail — a ativação avulsa não basta, porque o endereço é encerrado logo após o primeiro e-mail. Aqui é preciso alugar uma caixa por período, de 12 horas a 60 dias, com possibilidade de renovação: há presets de 12, 24 e 48 horas, uma semana, um mês e 60 dias, o que cobre tanto uma rodada curta de regressão quanto o teste de uma versão ao longo de vários dias.
Isolar dados de teste dos dados reais como regra
A regra é simples: os dados de teste não devem se misturar com os reais, nem nos endereços, nem nas contas, nem nos canais de notificação. A caixa alugada ajuda aqui de forma arquitetural — ela recebe e-mails apenas dos sites indicados no pedido, ou seja, o mesmo endereço de teste fisicamente não consegue receber por acidente uma mensagem de um serviço estranho e confundir o cenário. Isso é especialmente importante quando várias versões do mesmo produto ou vários ambientes são testados em paralelo: cada cenário deve ter o seu próprio endereço, para que os e-mails de rodadas diferentes não se misturem na mesma caixa e não atrapalhem o resultado da verificação.
O que registrar na documentação de testes
Para que a execução do teste possa ser reproduzida e explicada a um colega sem precisar perguntar, vale registrar na documentação do cenário três coisas: qual endereço exatamente foi usado, para qual site ou serviço ele foi pedido e qual é o seu prazo de validade — se expirou logo após o e-mail ou se ainda está ativo para uma verificação repetida. Sem esse registro, uma semana depois fica difícil entender por que a execução não pode ser repetida: o endereço foi encerrado automaticamente pelas regras do formato, e não porque algo quebrou no próprio cenário.
Quando as soluções gratuitas bastam e quando é mais simples alugar
Se você já tem um domínio próprio e uma hospedagem de e-mail com suporte a vários endereços, e o volume de cadastros de teste é pequeno, para verificações isoladas dá para se virar com isso — nem toda tarefa exige um endereço pago. Mas, quando os testes se multiplicam e os cenários exigem isolamento entre as rodadas e a garantia de que o e-mail de outro teste não vai parar na mesma caixa, é mais simples alugar uma caixa para uma tarefa ou site específico: isso elimina a administração e mantém cada cenário separado. Uma lógica parecida de escolha entre mock e código real em execuções automatizadas é explicada no artigo sobre testes automatizados com códigos reais no CI.
Perguntas frequentes
A ativação avulsa serve para testar o cenário de recuperação de senha?
Só se a recuperação for testada em uma execução separada, logo depois de receber o endereço. Se o cenário prevê primeiro o cadastro e a recuperação como uma etapa posterior, a ativação avulsa não basta: o endereço já estará encerrado. Para essa cadeia, é preciso alugar uma caixa por período.
O que fazer se o cenário de teste exige e-mails de vários serviços para um mesmo endereço?
Ao contratar o aluguel, é preciso informar logo todos os sites dos quais se esperam e-mails — o filtro da caixa aceitará mensagens apenas da lista informada, e não será possível adicionar um site depois.
E se há muitos testes e criar um endereço manualmente para cada um é inconveniente?
Se o aluguel e a ativação avulsa estiverem disponíveis via API, o pedido do endereço pode ser incorporado à preparação do ambiente de teste, obtendo o endereço de forma programática antes de cada execução, sem precisar fazer isso manualmente pela interface.
Você pode contratar uma ativação avulsa para o site testado ou alugar uma caixa pelo período do fluxo de ponta a ponta na seção email-OTP.