E-mail temporário em teste automatizado

Existe um ponto em quase todo teste de ponta a ponta onde a automação para e alguém precisa abrir uma caixa de e-mail. É a tela de "confirme seu endereço". O robô cria a conta, chega no link de confirmação, e não tem como seguir.

As saídas que os times costumam inventar para esse problema são todas ruins de um jeito diferente.

As três gambiarras clássicas

Desligar a confirmação no ambiente de teste. Rápido de fazer e cria um buraco: o fluxo que roda em produção deixa de ser o fluxo testado. O bug que aparece justamente na confirmação nunca vai ser pego, porque a confirmação não existe onde você testa.

Uma caixa de e-mail compartilhada. O time cria qa@empresa.com e todo teste usa esse endereço. Funciona até dois testes rodarem juntos — aí o teste A lê o link de confirmação gerado pelo teste B, confirma a conta errada e falha com uma mensagem que não faz sentido nenhum. Pior: falha de forma intermitente, que é o tipo mais caro de investigar.

Ler direto do banco. O teste consulta a tabela e pega o token sem passar pelo e-mail. É rápido e confiável, e testa um caminho que nenhum cliente percorre. Se o disparo do e-mail quebrar, o teste continua verde.

O que uma caixa temporária resolve

A ideia é simples: cada execução do teste cria um endereço novo, usa, e descarta.

O endereço é criado sob demanda por uma chamada de API. O teste usa aquele endereço no cadastro, consulta a caixa pela API para pegar o link, e conclui o fluxo. Depois a caixa expira sozinha.

Os três problemas acima somem de uma vez. O fluxo testado é o fluxo real, incluindo o disparo do e-mail. Não há colisão entre execuções paralelas, porque cada uma tem o próprio endereço. E não há limpeza para fazer depois, porque nada foi criado permanentemente.

O detalhe que separa um teste estável de um instável

E-mail não é síncrono. Entre o cadastro e a chegada da mensagem existe um intervalo que ninguém controla: a fila da aplicação, o provedor de envio, a entrega.

O erro que quase todo mundo comete é colocar uma espera fixa. sleep(5) e segue. Isso quebra dos dois lados: nos dias em que a entrega demora seis segundos, o teste falha sem motivo real; e nos dias em que demora meio segundo, você desperdiça quatro segundos e meio em cada execução do CI.

O certo é esperar pela condição, não pelo relógio: consultar a caixa em intervalos curtos até a mensagem aparecer, com um limite de tempo total para não pendurar o CI se ela nunca chegar. Melhor ainda quando o produto oferece aviso por webhook — aí o teste é avisado em vez de perguntar.

E vale um cuidado extra: quando o teste falha por tempo esgotado, a mensagem de erro precisa dizer que o e-mail não chegou. "Elemento não encontrado na página" manda quem for investigar para o lugar errado.

Além do teste automatizado