Existe um tipo específico de teste que a maioria dos times evita escrever até não dar mais para adiar: o teste end-to-end do fluxo de verificação por SMS. É fácil entender por quê. Mockar o envio é trivial. Testar o recebimento real — o código chegando de fato num número, sendo lido, sendo digitado de volta — é onde a maioria das suítes de teste desiste e parte para um mock que nunca falha, porque nunca testa nada de verdade.
Esse artigo trata da arquitetura por trás de fazer esse teste direito, e de onde um número real e controlado entra nesse desenho.
O problema de mockar demais
Mockar a chamada à API do provedor de SMS é necessário — ninguém quer pagar por cada execução de pipeline. Mas mockar cedo demais na cadeia esconde justamente as falhas que mais doem em produção: latência real de entrega, formato inesperado da mensagem recebida, comportamento de retry quando o código expira antes do usuário digitar, e o comportamento do app quando dois códigos chegam em sequência porque o usuário clicou "reenviar" duas vezes.
Um mock perfeito testa que o seu código lida bem com um mundo que não existe. Isso cria uma suíte verde que não impede o mesmo bug de aparecer no primeiro usuário real.
Onde a granularidade do teste deveria mudar
Faz sentido ter camadas diferentes de teste para esse fluxo, não uma suíte única:
Testes unitários cobrem a lógica de validação do código — expiração, formato, número de tentativas. Aqui, mock é não só aceitável como correto, porque o objetivo é isolar a lógica, não a infraestrutura de rede.
Testes de integração cobrem o contrato com o provedor de SMS — que a chamada de API está formatada certo, que erros são tratados, que timeouts não travam a aplicação. Ainda dá para usar sandbox do provedor na maioria dos casos.
Testes end-to-end são os únicos que deveriam, de fato, receber um SMS real, digitá-lo de volta, e validar o fluxo completo como um usuário validaria. É aqui que entra a necessidade de um número controlado pelo time, e não pessoal de um desenvolvedor específico.
Por que não usar o celular de alguém do time
Amarrar o teste E2E ao número pessoal de um desenvolvedor parece prático no início e vira dívida técnica rápido: a pessoa sai de férias, troca de aparelho, ou simplesmente não quer que o número dela receba SMS de teste sete vezes por dia. O pipeline quebra por motivo que não tem nada a ver com o código.
Um número dedicado, controlado pela organização e não por uma pessoa, resolve isso de forma direta — o teste continua rodando independente de quem está no time naquele mês.
Webhook vs polling para ler o SMS recebido
Depois de garantir um número estável, a próxima decisão de arquitetura é como o pipeline de teste lê a mensagem recebida. Duas abordagens comuns:
Webhook: o serviço que recebe o SMS notifica um endpoint assim que a mensagem chega. Mais rápido, mas exige expor um endpoint acessível durante a execução do teste, o que nem toda esteira de CI permite com facilidade.
Polling: o pipeline consulta periodicamente se uma nova mensagem chegou naquele número, até encontrar o código ou estourar um timeout. Mais simples de implementar dentro de um ambiente de CI fechado, ao custo de alguns segundos de latência a mais por execução.
Para a maioria dos times, polling com timeout curto (10 a 20 segundos) é suficiente e evita a complexidade de expor webhook publicamente só para o ambiente de teste.
Idempotência e o problema do "reenviar"
Todo fluxo real de verificação precisa lidar com o usuário clicando "reenviar código" antes do primeiro expirar. Isso gera dois códigos válidos simultaneamente, ou um código antigo sendo invalidado silenciosamente — comportamento que só aparece em teste se o cenário for simulado de propósito, com um número real recebendo as duas mensagens em sequência e o teste validando qual delas o sistema aceita.
Suítes que só testam o caminho feliz — um código, uma tentativa, sucesso — deixam esse comportamento sem cobertura, e ele normalmente aparece pela primeira vez em um ticket de suporte, não em um teste.
Onde o número virtual se encaixa nessa esteira
O componente que fecha essa arquitetura é um número que a organização controla de forma persistente, sem depender de chip físico, que pode ser consultado programaticamente pela esteira de CI e continua o mesmo entre execuções — o que evita reconstruir reputação e histórico a cada rotação de número. Um serviço como o numero virtual cobre exatamente essa função: número estável, próprio da organização, disponível tanto para teste manual quanto para automação via consulta programática.
Resumo
Testar verificação por SMS de forma real, e não só mockada, exige separar claramente onde cada tipo de teste deveria viver — unitário, integração, E2E — e resolver duas decisões de infraestrutura que aparecem só quando o teste é real: como o pipeline lê a mensagem recebida (webhook ou polling) e quem controla o número usado nesse processo. Resolver essa segunda parte com um número pessoal de alguém do time é a causa mais comum de pipelines de SMS que ficam frágeis sem motivo aparente; resolver com um número dedicado à organização remove essa fragilidade da equação.
Top comments (0)