Antes do fim do Google Jules em 2026, como migrar o fluxo de testes de e-mail?

Você usa o Jules para testar e-mails e ainda não salvou as instruções e configurações do fluxo?

Exporte e proteja os dados antes da mudança para somente leitura; depois, reconstrua as etapas no projeto ou na CI e confirme o recebimento real. A exportação não migra automaticamente o processo de testes.

Esta orientação é para você se desenvolve seu próprio produto com o Jules, executa regressões de e-mail como QA ou precisa organizar a transição do fluxo em uma equipe pequena. Não é um guia para migrar contas de usuário nem automatizar cadastros em serviços de terceiros.

Última atualização: 4 de novembro de 2026. Os marcos abaixo foram conferidos no comunicado oficial do Jules e precisam ser verificados novamente antes da publicação e da execução da migração.

O calendário do Jules define quando agir; não define uma ferramenta substituta

Segundo a atualização oficial, você pode continuar concluindo sessões até 11 de novembro de 2026. Depois, o serviço entra em modo somente leitura até o encerramento em 31 de dezembro de 2026. A atualização também informa que o código, as branches e os pull requests já estão no GitHub, enquanto a exportação local serve para preservar configurações e histórico que estão dentro do Jules. Consulte os marcos e a explicação oficial da exportação antes de iniciar.

A decisão operacional é simples: use a janela anterior ao modo somente leitura para salvar o que ainda está apenas no Jules e transforme os passos de teste que você comprovou em documentação e execução reproduzíveis. Não escolha uma ferramenta supondo que ela vá importar sessões, memória, tarefas agendadas ou configurações do Jules. A existência de uma alternativa automática não está confirmada pelas fontes oficiais citadas aqui.

A mudança também não significa que seu código deixou de existir. Código, branches e pull requests no GitHub são artefatos do repositório. Configurações, variáveis de ambiente, scripts de configuração, memória e histórico de sessões são materiais diferentes, e podem exigir exportação e revisão próprias. Não trate um item como cópia do outro.

Antes da leitura apenas, salve o que ainda existe no Jules

Faça a exportação usando o procedimento descrito na documentação oficial de exportação do Jules. Confira o conteúdo do arquivo gerado e registre, sem copiar valores secretos para uma documentação compartilhada, quais componentes são úteis ao fluxo de e-mail.

A exportação pode incluir:

• configurações e variáveis de ambiente;
• tarefas agendadas e vínculos com repositórios;
• memória e scripts de configuração;
• histórico das sessões.

Considere essa lista um inventário para revisão, não uma receita pronta para importar em outro ambiente. O histórico pode mostrar qual comando foi executado, mas não prova que o comando ainda funciona, que aponta para o ambiente certo ou que o teste verificou a chegada da mensagem.

O que você deve guardar antes da mudança para somente leitura? Preserve a exportação original em um local com acesso restrito. Em seguida, extraia para a documentação do projeto somente o que pode ser compartilhado: objetivo do teste, comandos, pré-requisitos, nomes das variáveis e regras de validação. Guarde os valores secretos em um gerenciador apropriado, não em logs, tickets, mensagens ou no repositório.

O arquivo de exportação pode conter dados que dão acesso a ambientes ou serviços. Restrinja quem pode consultá-lo e evite adicioná-lo ao Git por conveniência. A orientação da OWASP sobre gerenciamento de segredos reforça a necessidade de controlar o acesso e evitar exposição indevida. Para fluxos do GitHub Actions, use o mecanismo de Secrets documentado pelo GitHub, em vez de gravar credenciais diretamente nos arquivos do workflow.

Separe nome e valor. Por exemplo, documente que o processo usa MAIL_TEST_RECIPIENT e explique em que cenário ele é necessário; não copie o endereço real nem um token para um arquivo de instruções. Registre também onde a variável deve ser configurada, quem administra o acesso e como atualizar o segredo. Não inclua o valor em mensagens de erro: logs de CI podem ser acessíveis a mais pessoas do que o ambiente de execução.

Organize o fluxo reutilizável, não o histórico bruto

A exportação serve como fonte de consulta. Antes de reaproveitar qualquer instrução, compare-a com o código atual e com o comportamento esperado do seu produto. Uma sessão pode ter sido criada para uma versão anterior, usar um serviço de teste que não está mais disponível ou depender de uma condição que ficou implícita na conversa.

Monte uma descrição curta para cada cenário de e-mail que você realmente precisa manter. Um teste de cadastro, por exemplo, deve identificar o estado inicial da conta, a ação que dispara a mensagem, o endereço controlado que recebe o e-mail e a mudança esperada depois da validação. Um fluxo de redefinição de senha pode exigir verificações diferentes: não misture as duas finalidades em uma única instrução vaga.

Como seguir testando o e-mail de cadastro do seu produto depois do Jules? Recrie o cenário com uma conta de teste exclusiva, uma caixa de recebimento controlada e as etapas observáveis do cadastro. Registre o que deve acontecer antes e depois do clique no link, e como limpar ou invalidar os dados de teste. Execute somente contra uma aplicação sua ou um ambiente em que você tenha autorização.

Para cada cenário, extraia do histórico apenas informações que você consiga verificar:

• o comando ou a ação que inicia o teste;
• os pré-requisitos do ambiente e os dados sintéticos necessários;
• o endereço de recebimento e quem controla o acesso a ele;
• as verificações do conteúdo e do comportamento da aplicação;
• o tratamento de falha, repetição e limpeza dos dados.

Se um detalhe não puder ser confirmado, marque-o como pendente. Não converta uma hipótese escrita em uma sessão em procedimento oficial. Uma instrução antiga pode ter usado uma URL temporária, uma variável local ou uma permissão que não existe mais. Confirme cada dependência no projeto e na configuração vigente antes de reproduzi-la.

Para diminuir o risco de dados pessoais em ambientes de desenvolvimento, use informações sintéticas e endereços dedicados aos testes. Evite encaminhar mensagens de teste para caixas pessoais de colegas, sobretudo se o corpo do e-mail contiver links de redefinição ou outros dados de acesso. Você pode consultar as orientações de privacidade e tratamento de dados ao definir que informações não devem aparecer em mensagens ou evidências de teste.

Reconstrua no projeto ou na CI; não presuma que as configurações acompanham você

O novo fluxo precisa ter um ponto de entrada conhecido pela equipe. Ele pode ser uma instrução executável no projeto ou uma etapa de CI, desde que deixe explícitos o ambiente alvo, as variáveis necessárias, os critérios de sucesso e o que deve ser limpo ao final. A escolha depende de como sua equipe já executa testes; não é necessário reproduzir a forma como o Jules organizava as sessões.

Ao usar GitHub Actions, configure as variáveis e credenciais no contexto apropriado. O GitHub explica como associar workflows a ambientes de implantação e suas configurações. Isso ajuda a separar valores por ambiente, mas não significa que os dados exportados do Jules serão reconhecidos ou importados automaticamente.

As variáveis exportadas podem ser colocadas diretamente no novo ambiente? Não sem revisão. Primeiro confira se cada nome ainda é necessário, se o valor continua válido e se o destino é o ambiente correto. Não transfira segredos antigos em bloco: uma variável de teste pode apontar para produção, conceder acesso além do necessário ou depender de uma configuração que já mudou. Configure o segredo de forma controlada e faça uma execução que não exponha seu valor.

Descreva as etapas no próprio projeto para que outra pessoa consiga repeti-las sem depender da memória de quem operava o Jules. Para cada execução, deixe claro:

• qual ambiente recebe a ação;
• qual evento dispara o e-mail;
• qual caixa ou endereço controlado deve receber;
• quais partes da mensagem e do estado da conta devem ser conferidas;
• como interromper e limpar a execução sem afetar dados reais.

Não registre credenciais no comando de exemplo, no arquivo de configuração versionado ou na saída do teste. Se o processo exigir um segredo, a documentação deve apontar para o mecanismo de configuração, não reproduzir o valor. Essa separação permite revisar o procedimento sem conceder acesso a quem só precisa entender o teste.

Na primeira execução, diferencie o teste aprovado do e-mail recebido

Rode primeiro em um ambiente isolado do seu produto, com conta e dados de teste. Observe separadamente o disparo da aplicação, a chegada da mensagem à caixa controlada, o conteúdo recebido e a conclusão do fluxo funcional. Uma verificação automatizada pode afirmar que o endpoint foi chamado ou que uma resposta foi gerada; isso não comprova, por si só, que a mensagem chegou à caixa de destino.

Como comprovar que a mensagem ainda é recebida depois da migração? Acompanhe o caminho completo: acione a função no seu produto, verifique que o serviço de envio aceitou a solicitação, confira a caixa de recebimento controlada e valide o conteúdo e o link. Depois, confirme que a ação esperada — como ativar a conta — alterou o estado do produto. Se uma dessas evidências faltar, registre a etapa como não comprovada, mesmo que o job de CI termine com sucesso.

Na revisão, mantenha evidências sem expor dados sensíveis. Registre o resultado, o horário da execução se for útil para correlacionar logs, o ambiente e qual critério foi satisfeito. Não copie tokens de acesso, links válidos de redefinição ou corpos com dados pessoais para relatórios compartilhados. Se o endereço de recebimento ou o mecanismo de captura não estiver disponível, o teste pode cobrir a lógica da aplicação, mas não deve ser descrito como confirmação de recebimento real.

Para facilitar a triagem, diferencie falhas possíveis em vez de usar um único status genérico:

• a aplicação não acionou o envio;
• o envio foi solicitado, mas a mensagem não apareceu na caixa controlada;
• a mensagem chegou, porém o conteúdo ou o link está incorreto;
• o conteúdo está correto, mas a aplicação não concluiu a mudança de estado;
• a execução não gerou evidência suficiente para afirmar o resultado.

Essa separação ajuda você a localizar se o problema está na lógica do produto, no envio, no recebimento ou na asserção automatizada. Também evita que uma falha de infraestrutura seja confundida com defeito no template, ou que um teste de código aprovado seja usado como prova de que o e-mail foi recebido.

Uma lista de conferência para encerrar a migração

Use esta lista como registro de execução. Marque cada item somente depois de verificar o resultado; itens ainda incertos devem permanecer pendentes, e não ser tratados como concluídos.

• [ ] Exporte os dados do Jules e confirme que o arquivo pode ser aberto.
• [ ] Restrinja o acesso à exportação original e não a envie ao repositório.
• [ ] Separe instruções reutilizáveis, nomes de variáveis e valores secretos.
• [ ] Confira no projeto quais comandos e dependências ainda funcionam.
• [ ] Defina um ambiente autorizado e isolado para a execução.
• [ ] Configure os segredos no mecanismo adequado, sem incluí-los em logs.
• [ ] Documente o endereço de recebimento controlado e quem pode acessá-lo.
• [ ] Execute o fluxo de cadastro ou outro cenário de e-mail do seu produto.
• [ ] Verifique a chegada real, o conteúdo da mensagem e o resultado funcional.
• [ ] Registre etapas não verificadas e dependências ainda ligadas ao Jules.
• [ ] Revise a documentação quando o estado oficial do serviço mudar.

A lista não substitui os testes. Ela evita que a equipe confunda “exportação concluída” com “fluxo migrado” e ajuda a identificar o que ainda depende de uma sessão antiga. Para estruturar a validação sem omitir verificações importantes, você também pode consultar esta lista de conferência para testes de e-mail.

Depois da migração, revise o que ficou pendente em cada marco

Compare o procedimento novo com o antigo por objetivo, entrada de execução, configuração e evidência de recebimento. Não compare apenas os comandos. Um comando semelhante pode operar em outro ambiente ou comprovar uma etapa diferente.

Antes de 11 de novembro de 2026, verifique se você preservou o material que ainda precisa consultar enquanto as sessões podem ser concluídas. Depois dessa data, segundo a atualização oficial, o Jules fica somente para leitura até o encerramento previsto em 31 de dezembro de 2026. Use esses marcos como lembretes para revisar o estado do serviço, e não como garantia de que uma exportação ou migração ocorreu sem erros. As datas e a condição do serviço estão descritas no histórico oficial de atualizações do Jules.

Mantenha uma relação explícita do que está comprovado, do que falta testar e do que ainda depende de configuração antiga. Se a evidência de recebimento real não foi obtida, o fluxo não está validado para esse critério. Se os testes funcionais foram aprovados, mas não verificaram a caixa de destino, registre exatamente isso, sem ampliar a conclusão.

O objetivo é preservar o conhecimento útil sobre os testes do seu produto, não preservar cada conversa nem encontrar uma cópia exata do Jules. Quando o processo estiver documentado e repetível, outra pessoa deve conseguir executar o cenário, interpretar a falha e confirmar o resultado sem depender do histórico do agente.

Para verificar recebimento em um cenário controlado, um endereço temporário pode ser uma opção quando o teste não exige uma caixa permanente, respostas por e-mail ou recuperação futura de uma conta importante. O MSGTMP pode entrar nessa etapa como destino de teste; consulte a página do serviço antes de decidir se atende ao seu caso e não presuma compatibilidade, retenção ou entrega garantida. Se a sua validação exige histórico duradouro ou recuperação de conta, mantenha um endereço sob controle contínuo da equipe. Para um teste pontual de cadastro do seu próprio produto, o MSGTMP pode ajudar a separar a mensagem de teste da caixa principal sem transformar a migração em mais uma tarefa de manutenção.