Há um momento em que a automação precisa parar de fingir e esperar por algo que vem de fora: o código OTP em testes automatizados é o passo em que a suíte deixa de controlar tudo e passa a depender de uma mensagem que outro sistema enviou. É também o passo mais frágil de qualquer fluxo de cadastro automatizado, porque envolve tempo, concorrência e limite de reenvio. Este texto mostra como montar esse trecho para que ele falhe de forma compreensível.
O passo que ninguém quer automatizar
Um código de uso único é a prova de que quem está do outro lado tem acesso a um canal que o sistema enviou. Para a automação, ler esse código significa abrir uma caixa de entrada, encontrar a mensagem correta e extrair o trecho que interessa.
O incômodo vem de que esse passo é intrinsecamente assíncrono. Todo o resto do teste roda em milissegundos; a mensagem pode levar muito mais tempo. Uma suíte que trata esse trecho como os outros acaba cheia de pausas fixas e de falhas intermitentes, e a equipe aprende a rodar tudo de novo em vez de investigar.
Como o teste encontra a mensagem certa?
A resposta ingênua é pegar a primeira mensagem da caixa. Ela funciona enquanto a caixa está vazia, e para de funcionar exatamente quando você mais precisa: o endereço recebeu uma mensagem de outro caso, ou uma mensagem antiga ficou ali de uma execução anterior.
A resposta robusta tem três partes:
- Isole o destino. Um endereço por caso de teste, ou ao menos um identificador único que o remetente devolve na própria mensagem.
- Identifique pelo que você controla. O assunto esperado ou o destinatário exato, em vez de qualquer mensagem que por acaso esteja na caixa.
- Escolha por ordem de chegada. Quando houver mais de uma candidata compatível, a mais recente é a que corresponde ao código atual.
Vale ainda decidir o que fazer quando nada corresponde. Uma falha que diz que a caixa continha três mensagens e nenhuma com o assunto esperado economiza horas; uma falha que diz apenas que o código não foi encontrado obriga a reproduzir tudo.
Por que o código antigo aparece no meio do caminho?
Esse é o sintoma mais confuso da categoria. O teste procura o código atual, encontra um número que parece válido e o usa. O sistema recusa, e a investigação começa no lugar errado, porque o problema não está na extração, e sim na escolha da mensagem.
A causa costuma ser uma destas três. A caixa é compartilhada entre casos e acumulou mensagens. A expressão que localiza o código aceita qualquer sequência de dígitos e encontra a primeira que aparece no texto, inclusive uma data ou um número de pedido. Ou o sistema reenviou a mensagem e agora existem duas versões, com códigos diferentes, e o teste leu a primeira.
A defesa é sempre a mesma: amarrar a leitura ao caso. O código não é um número solto, é o número que pertence àquela execução.
O limite de reenvio é parte do comportamento
Quando a automação não encontra a mensagem, a reação instintiva é pedir outra. Só que o reenvio costuma ter limite, e o limite existe por um bom motivo: sem ele, seria possível usar o serviço como ferramenta de incômodo contra o dono de qualquer endereço. Gastar esse limite em tentativas cegas faz o teste falhar por um motivo que não é o defeito investigado.
A recomendação é separar os dois assuntos. O teste de leitura deve consultar a caixa até encontrar a mensagem, com um limite de tempo, e só pedir reenvio quando houver motivo concreto. E o limite de reenvio merece um teste próprio, que verifique se ele é respeitado, se a mensagem de erro é clara e se o prazo de espera é informado. Uma coisa é confirmar que o fluxo funciona; outra é confirmar que ele se defende.
Uma caixa descartável para receber o código
Para exercitar tudo isso sem tocar em endereços de trabalho, a ferramenta de e-mail temporário resolve: você cria um destino por execução, cola no formulário e lê o que chegou. Como o endereço é de uso curto, é natural descartá-lo depois, e o próximo caso começa com a caixa vazia.
Vale reforçar uma distinção: os códigos que aparecem nesse tipo de teste são dados efêmeros de um sistema sob verificação, e não credenciais de uma pessoa. O endereço temporário é um instrumento de teste, nunca um contato real de alguém.
Se o seu fluxo separa o envio do link do envio do código, o texto sobre teste do fluxo de verificação trata do roteiro maior em que este passo se encaixa.
Para quem desenvolve: extração robusta e limites de espera
O primeiro cuidado é com a expressão que localiza o código. Uma busca por qualquer sequência longa de dígitos encontra números que não são códigos, como identificadores de pedido ou carimbos de data. Amarrar a busca ao formato real do seu código — o mesmo comprimento, o mesmo contexto na mensagem — reduz muito o ruído.
O segundo é a escolha da mensagem. Prefira filtrar pelo destinatário exato e pelo assunto, e entre as candidatas ficar com a de data mais recente. Se o seu produto envia mais de uma mensagem para o mesmo endereço, a ordenação por data é a única forma confiável de saber qual é a atual.
O terceiro é o limite de espera. Definir quanto tempo o teste aguarda antes de desistir, e registrar o estado da caixa nesse momento, evita investigações longas. Vale ainda diferenciar dois fracassos: a mensagem não chegou e a mensagem chegou mas não foi possível extrair o código. São defeitos de naturezas diferentes.
O quarto é a extração em si. Guarde o trecho encontrado no relatório do teste. Quando um código é lido errado por causa de um caractere parecido, ver o que a máquina leu resolve o mistério imediatamente.
Por último, mantenha um caminho manual para os casos em que a leitura automática não é possível. Um teste que exige intervenção humana não deve estar na suíte principal, mas também não deve ser esquecido: ele pertence a uma bateria separada, executada quando alguém assume a responsabilidade de acompanhar.
Próximos passos
Pegue o teste mais instável do seu fluxo de cadastro e verifique como ele escolhe a mensagem. Se a resposta for a primeira da caixa, substitua por uma escolha amarrada ao caso. Para criar os destinos dessa bateria, use a ferramenta de e-mail temporário e entenda por que uma mensagem pode demorar antes de concluir que o código não chegou.