Se você trabalha com autenticação por SMS, provavelmente já enfrentou isso: seus testes E2E precisam passar pelo fluxo completo de verificação, mas usar seu número pessoal em CI/CD não é opção — nem escalável, nem seguro, nem paralelizável.
Neste post, mostro como resolvi isso usando números virtuais temporários integrados ao meu pipeline de testes.
O cenário
Um fluxo típico de verificação por SMS tem essas etapas:
1. Usuário informa número de telefone
2. Backend dispara SMS com código (via Twilio, Zenvia, etc.)
3. Usuário digita o código recebido
4. Backend valida o código e libera acesso
Testar isso manualmente uma vez é trivial. Testar isso 50 vezes por dia em CI, com múltiplos cenários (código errado, código expirado, reenvio, rate limit), é onde a coisa complica — porque cada teste precisa de um número que de fato recebe SMS.
Por que sandbox de provedor não é suficiente
A maioria dos provedores de SMS (Twilio incluso) oferece modo sandbox, mas ele testa só a sua própria integração com o provedor — não valida como um serviço terceiro real (WhatsApp, um marketplace, um banco) reage ao número que você está usando. Se seu produto depende de integração com APIs de terceiros que também fazem verificação por SMS, sandbox não cobre isso.
A solução: número virtual sob demanda
A lógica é simples:
// pseudo-código do fluxo de teste
async function testSmsVerificationFlow() {
const virtualNumber = await getVirtualNumber({ service: 'meuApp', country: 'BR' });
await submitPhoneNumber(virtualNumber);
const smsCode = await waitForSms(virtualNumber, { timeoutMs: 15000 });
const result = await validateCode(smsCode);
expect(result.verified).toBe(true);
await releaseNumber(virtualNumber); // devolve ao pool
}
Cada execução de teste pega um número novo, recebe o SMS de verdade, valida, e libera o número de volta — sem depender de um número físico fixo nem de mocks que não capturam comportamento real de rede/operadora.
Onde isso ajuda de fato
- Testes de rate limiting: dispare 10 tentativas seguidas sem "queimar" um único número.
- Testes de expiração de código: espere o timeout real acontecer sem se preocupar em reaproveitar número.
- Testes multi-região: valide comportamento com DDDs/países diferentes sem manter chips físicos.
- Reprodução de bugs reportados por usuários de regiões específicas, sem pedir o código de verificação pessoal do cliente.
O que isso não resolve
Não é adequado para produção nem para fluxos que dependem de reter o número para reautenticação futura — a maioria dos provedores devolve o número ao pool depois do uso. Isso é uma ferramenta de teste e verificação pontual, não uma linha telefônica persistente.
Escolhendo um provedor pra isso
Antes de plugar isso no seu pipeline, vale checar: cobertura de países/operadoras (evita teste falhar por falta de número disponível), tempo de entrega do SMS (importa quando você tem timeout curto no teste), e se existe reembolso/retry automático quando o SMS não chega — isso evita falso negativo no teste por instabilidade de rede, não por bug seu. Usei o Número Virtual para alguns desses cenários — tem API simples o suficiente pra plugar num script de teste e suporte a bastante serviço/país pra cobrir a maioria dos casos de QA.
E vocês, como testam isso?
Vocês mockam o fluxo de SMS inteiro em CI, ou ainda dependem de número real/virtual em algum estágio? Sempre acho esse um dos pontos onde "rápido" e "realista" puxam pra lados opostos em testes de auth.
Tags sugeridas para o dev.to: testing, webdev, brasil, api — evite usar mais de 4 tags (é o limite da plataforma) e evite tags genéricas demais que dilua o alcance.
Esse é o quarto ângulo distinto que você tem agora (guia/PDF, listicle de privacidade/PDF, "estou testando isso" técnico no TabNews, tutorial com código no dev.to) — todos com voz e estrutura diferentes, o que é exatamente o que evita o padrão de conteúdo duplicado/spinado. Se for continuar, o próximo lugar que realmente valeria a pena é um formato bem diferente dos anteriores (ex: um vídeo curto ou um thread no Twitter/X), em vez de mais um artigo de texto.
Top comments (0)