O ambiente de teste é conectado ao serviço de produção uma vez, só para uma verificação, e ninguém lembra de desconectar. Um mês depois, a execução automática cria dezenas de contas reais no serviço de produção, e o gateway de pagamento cobra dinheiro de verdade por um pedido de teste. O problema não está na execução em si, e sim no fato de que o ambiente de teste e a produção não estão separados no nível da configuração. Vamos ver como isso acontece e o que verificar para que uma execução automática não vire um incidente em produção.

A falha típica: como uma execução de teste cria contas reais

O cenário é quase sempre o mesmo: a configuração do ambiente de teste foi clonada da produção, parte dos valores foi trocada, mas o endereço da API ou a chave de acesso ficou para trás. As execuções rodam por meses sem problemas, até que uma delas toca o endpoint de cadastro ou de pagamento. Aí aparecem no banco de produção contas reais com nomes de teste como test_user_1, e no gateway de pagamento surgem cobranças reais por pedidos de teste.

Pior ainda se a falha não for notada de imediato: essas contas ficam semanas em produção, entram na análise de dados, distorcem as métricas de conversão e se misturam com usuários de verdade na hora de investigar incidentes.

Separação das configurações de teste e produção por chaves e endereços

A forma mais segura de não depender da memória é separar fisicamente as configurações: o ambiente de teste tem o seu próprio conjunto de chaves de acesso, o seu próprio endereço de API e o seu próprio domínio de retorno de chamadas. Um arquivo de configuração comum com um seletor «teste/produção» é a origem da maioria dos acidentes, porque o seletor pode ser esquecido ou trocado por engano no deploy.

Vale conferir o formato das chaves na documentação, por exemplo na documentação da API de aluguel de números: muitas vezes a chave de teste e a de produção são visualmente quase idênticas, e a diferença só aparece pelo prefixo ou pela seção da área do cliente em que a chave foi emitida.

Pool separado de números e caixas de e-mail para as execuções

Esse tipo de execução precisa de números e caixas de e-mail reais, sem isso não dá para testar o recebimento de SMS ou do e-mail de confirmação. O erro é pegá-los do pool de produção compartilhado: um número ocupado pelas execuções sai da venda e, depois da execução, pode ficar vinculado a uma conta real que ninguém planejava criar.

O esquema correto é um pool separado, com o status «teste» atribuído já na etapa de entrega, e um registro próprio para ele: os mesmos campos dos recursos de produção, ou seja, ambiente, data e estado. Como esse registro funciona de modo geral está explicado no artigo inventário de números, e-mails e IPs.

Sinais de que o ambiente de teste está apontando para o lugar errado

Alguns sinais que vale verificar antes de cada release de configuração: nos logs do ambiente de teste aparece o domínio de produção ou um endereço de produção do pool de rotação por API; o contador da análise de produção cresce em sincronia com a execução automática; no e-mail de suporte de produção chegam mensagens automáticas com nomes de teste; o saldo da carteira de produção diminui sem nenhuma ação manual, justamente quando só deveria estar rodando uma execução de teste.

Qualquer um desses sinais é motivo para interromper a execução imediatamente, e não para acrescentar a ela a condição «pular em produção».

A regra «a chave de teste não deve existir em produção» e o checklist antes da primeira execução

A regra mais segura é mais simples do que qualquer monitoramento: a chave do ambiente de teste fisicamente não deve existir no ambiente de produção, e a chave de produção não deve existir no de teste. Não «desativada por padrão», e sim ausente: assim, uma chamada feita por engano falha na autorização em vez de chegar ao serviço de produção.

Antes da primeira execução automática, vale verificar quatro coisas: o endereço da API e a chave de acesso na configuração do ambiente de teste não foram copiados da produção; o pool de números e e-mails da execução é separado e marcado como de teste; no ambiente de teste há um limite de operações, para que um erro não se multiplique em centenas de requisições antes de ser notado; e os logs da execução estão disponíveis na hora, e não só depois de um pedido manual.

Perguntas frequentes

Como verificar rapidamente que o ambiente de teste não aponta para a produção?

Faça uma chamada de teste bem visível, por exemplo criando um recurso com um nome único, e verifique se ele apareceu na área de produção. Se apareceu, a configuração está trocada.

Posso usar números de produção para uma execução curta?

Não: mesmo uma execução curta ocupa um recurso do pool de produção e, se a limpeza falhar, o recurso não volta para a venda a tempo.

O que fazer se contas reais já foram criadas por uma execução de teste?

Exporte essas contas por um traço identificador, como o prefixo do nome ou uma data de criação fora do tráfego normal, exclua ou desative manualmente e depois elimine a causa: a chave compartilhada ou o endereço de API compartilhado.

Se você precisa de um pool separado de números e e-mails reais para testes, sem risco para os dados de produção, na seção de aluguel de números e e-mails os recursos são entregues individualmente e, por padrão, não se cruzam com os ambientes de outras pessoas.