Um mock no lugar do código SMS real no teste de cadastro valida o formulário, mas não o cenário completo: ele não pega atraso na entrega, formato inesperado de código de um serviço específico, nem falha na etapa de digitar o e-mail de confirmação. Rodar com um código de verdade é a única forma de ter certeza de que a cadeia de cadastro está viva, do primeiro pedido de número até o login na conta.

Por que você precisa de um cenário com código real

O código mockado sempre chega na hora e no formato esperado — a realidade é outra. A operadora pode atrasar a entrega em 20–40 segundos, o código pode chegar em dois SMS em vez de um, e o e-mail de confirmação pode cair numa fila de moderação do lado do serviço de e-mail. Nenhum desses cenários é reproduzido por um mock, e são justamente eles que mais derrubam o cadastro em produção, que ficou meses sem ser tocado.

O segundo argumento é a integração como um todo. O teste com código real verifica não só o parsing do SMS, mas toda a cadeia: pedido de número via API, entrega do código até o seu lado, extração do código do texto, preenchimento no formulário e finalização da ativação. Uma falha em qualquer elo é um bug que vale a pena pegar no CI, e não em produção.

Como funciona a execução de ponta a ponta

O cenário se apoia em três etapas. A primeira é o pedido de um número ou endereço de e-mail via API antes de começar o cadastro na plataforma de destino. A segunda é a espera pelo código: ele não chega instantaneamente, então o pipeline consulta o status em intervalos fixos, em vez de esperar sozinho com um único timeout. A terceira é a finalização: o código é inserido no formulário, o cadastro é concluído e o próprio número ou endereço é marcado como usado, para não fazer um novo pedido de código que já não vai chegar.

O timeout de espera pelo código deve ter folga em relação à entrega normal: se o código costuma chegar em 10–15 segundos, o razoável é configurar o timeout do pipeline em 60–90 segundos, e não em 15. Repetir o pedido de código faz sentido uma vez, depois do primeiro timeout esgotado — a segunda tentativa pega um atraso raro da operadora, e a terceira normalmente indica um problema real na cadeia, e não uma flutuação na entrega.

Por que é uma execução separada e rara, e não parte de cada commit

O teste com código real custa dinheiro a cada execução — o número ou endereço é cobrado independentemente do resultado — e depende de um serviço externo, cujo atraso você não controla. Rodá-lo a cada commit significa pagar por cada push na branch e receber builds vermelhos aleatórios, não por culpa do código, mas por causa de um atraso externo na entrega.

O esquema que funciona é manter os testes rápidos com mock no pipeline normal a cada commit e levar o cenário com código real para uma execução separada e rara: antes do release, uma vez por dia agendada ou manualmente antes do merge na branch principal. Isso pega regressões reais na cadeia de entrega sem inflar o custo e o tempo do build comum.

Isolamento dos dados de teste em relação aos de produção

Números e endereços de e-mail para os testes automatizados devem vir de um pool separado, e não do mesmo saldo usado para as tarefas de produção: misturar dificulta o controle de gastos e cria o risco de um teste pegar por acaso um número reservado para um processo de produção. As contas criadas pelo teste devem ser marcadas com um prefixo próprio ou um domínio de e-mail específico e limpas conforme um cronograma — caso contrário, os registros de teste se acumulam nas mesmas tabelas dos usuários reais e atrapalham a análise.

Controle de custos das execuções

Cada execução com código real é uma cobrança pelo número ou endereço de e-mail mais o tempo de execução no pipeline. Vale calcular o custo de um cenário completo e multiplicar pela frequência das execuções: uma vez por dia é uma ordem de orçamento, a cada commit numa branch ativa é outra completamente diferente, várias vezes maior, sem crescimento proporcional do benefício. Uma referência razoável é manter as execuções raras com códigos reais frequentes o bastante para pegar regressões antes do release, mas raras o bastante para que o custo do CI não compita com o custo do próprio serviço.

Perguntas frequentes

Dá para abandonar totalmente os mocks em favor de códigos reais?

Não faz sentido: o mock é rápido, gratuito e serve para verificar a lógica de parsing e do formulário a cada commit. O código real é necessário para um cenário de ponta a ponta separado, que pega problemas de integração e entrega, e não para testar o código do aplicativo a cada alteração.

O que fazer se o código não chegar dentro do timeout definido?

Uma nova tentativa de pedido é um primeiro passo razoável: ela absorve um atraso ocasional da operadora. Se o código não chegar nem depois da repetição, o teste deve falhar de forma explícita e clara, e não ficar travado até o timeout geral do pipeline — isso economiza tempo de análise e aponta claramente para um problema na cadeia de entrega, e não para uma flutuação.

Com que frequência rodar a execução com códigos reais?

Uma opção prática é uma vez por dia, agendada, mais uma execução obrigatória antes do release na branch principal. Esse ritmo pega regressões em um prazo razoável e mantém o gasto com números e endereços previsível, sem atrelá-lo ao número de commits do desenvolvimento ativo.

Como funciona o pedido de número e a consulta do status do código no lado da API está detalhado na documentação da API. Você pode obter um número para a primeira execução de teste na seção OTP, e o princípio de consultar o estado via API é o mesmo usado na rotação de IP via API. O gasto com as execuções regulares é fácil de acompanhar no histórico de transações.