2026 Bun 1.4.4 --changed: o que fazer quando os testes de verificação de e-mail são ignorados?

Comece pela relação entre os arquivos alterados e os testes

Quando bun test --changed não mostra um teste de verificação de e-mail, não conclua de imediato que existe um defeito no Bun nem que a funcionalidade está sem cobertura. Primeiro, determine o que mudou e qual referência Git a execução usou. Depois, compare esses arquivos com os testes que apareceram na saída.

A documentação do Bun 1.4 e o guia oficial de testes descrevem a seleção incremental com base nas alterações e na relação entre arquivos de código e testes. Na prática, isso significa que um teste pode não entrar na execução se o arquivo modificado não estiver relacionado a ele de uma forma que o runner consiga identificar. A documentação define o mecanismo; a saída da sua versão e do seu ambiente mostra o que ocorreu naquele job.

Não confunda três situações:

• O runner encontrou e iniciou um arquivo de teste.
• As asserções desse arquivo passaram.
• O processo de envio da aplicação produziu uma mensagem que foi realmente recebida.

Cada situação exige uma evidência diferente. A saída com código de sucesso demonstra que a execução terminou sem falha detectada pelo processo. Ela não demonstra que todos os testes de e-mail do repositório foram selecionados, nem que houve entrega externa.

Comece registrando a referência de comparação usada no comando. Em seguida, veja quais arquivos entraram no diff e compare a lista com os testes de cadastro, geração da mensagem e consumo do link. Se o job compara com uma referência diferente daquela que você supôs, a seleção pode representar outro conjunto de alterações.

Meça a cobertura da mudança antes de interpretar o resultado

O que verificar quando bun test --changed não roda o teste de e-mail?

O comando incremental serve para reduzir o conjunto executado com base no que mudou; não é uma promessa de rodar todo o conjunto de regressão de e-mail. Para investigar, inspecione os nomes dos arquivos modificados no Git e a saída do Bun. Não parta da ideia de que a palavra “changed” significa “todos os testes relacionados ao comportamento afetado”, especialmente quando há dependências indiretas.

Uma verificação inicial pode ser feita assim:

git diff --name-only origin/main...HEAD
bun test --changed origin/main

Use a referência que o projeto realmente adota como base. O exemplo não substitui a configuração do seu repositório: confirme que origin/main existe no ambiente do CI, que a referência foi buscada e que a forma de comparação corresponde ao fluxo de branches da equipe. A documentação do Bun descreve --changed e os argumentos aceitos; confira a sintaxe da versão instalada antes de tratar o comando como uma regra universal.

Depois, classifique as mudanças. Um arquivo de template de e-mail, o manipulador de cadastro, a função que cria o link de verificação e o código que consome esse link podem participar do mesmo fluxo, mas não necessariamente mantêm uma relação de importação direta com o teste. O teste pode importar uma camada intermediária; a aplicação pode montar uma dependência por configuração; uma etapa de geração pode criar o arquivo utilizado em tempo de execução. Nesses casos, confirme qual relação o runner consegue observar.

A tabela organiza perguntas de diagnóstico, não afirma que o Bun sempre detectará cada uma dessas relações. A seleção depende do grafo de arquivos que o processo consegue observar. Quando o caminho é indireto ou dinâmico, não deixe a cobertura crítica depender exclusivamente da seleção incremental.

Como conferir quais arquivos entraram na execução em Bun 1.4.4?

Registre o comando completo, a referência de comparação, a versão do Bun e a lista de testes executados. Se a saída padrão não for suficiente para auditar o job, ajuste o comando ou a configuração para expor os nomes dos arquivos e dos testes, usando apenas opções documentadas para a versão instalada. Não deduza a lista executada pelo tempo de execução, pela quantidade de linhas de saída ou pelo código de saída do processo.

A publicação oficial de Bun 1.4.4 informa correções de estabilidade para bun test e bun test --changed. Esse registro é importante para identificar o contexto da versão, mas não atribui uma causa universal a um teste de e-mail ausente. A nota de lançamento não diz que o runner oferece uma função especial para testar e-mails. Se a seleção parecer incorreta, reproduza o comando com a mesma referência em um ambiente comparável, examine os arquivos selecionados e compare o resultado com uma execução explícita dos testes relevantes.

Se você só sabe que o comando terminou com sucesso, ainda falta saber quais arquivos foram executados. Para reduzir essa lacuna, mantenha uma tarefa separada e nomeada para os testes críticos de e-mail. O guia de configuração de testes do Bun ajuda a conferir como a configuração do projeto afeta a execução; registre as opções relevantes no próprio pipeline, em vez de depender de suposições feitas a partir da configuração local.

Separe teste de conteúdo, fluxo da aplicação e entrega

Uma validação de e-mail pode abranger etapas distintas, e cada uma sustenta apenas uma conclusão limitada. Um teste unitário pode verificar que a aplicação montou o assunto e o corpo esperados. Um teste de integração pode confirmar que a solicitação de cadastro chamou o componente de envio e que o usuário ficou em um estado pendente. Uma verificação com um endereço controlado pode confirmar que a mensagem ficou acessível no destino consultado.

Essas etapas não são intercambiáveis. Se o teste usa um mock para o componente de envio, ele pode comprovar que a aplicação pediu o envio com certos dados; não demonstra que um serviço externo aceitou a mensagem. Se a aplicação registra que o envio foi iniciado, isso ainda não confirma que a mensagem chegou. E, se houve recebimento, a evidência deve estar ligada à execução em questão: destinatário isolado, conteúdo esperado e identificador ou dado de correlação que permita reconhecer a mensagem certa.

Para organizar a investigação, mantenha evidências separadas:

Use um identificador de teste não sensível no assunto, no corpo ou nos metadados permitidos pelo seu sistema, se isso ajudar a correlacionar a mensagem sem expor dados pessoais. Não inclua tokens válidos em logs compartilhados. Se o link de verificação for segredo de uso único, registre apenas o necessário para comprovar o resultado, não o próprio valor reutilizável. Para rever o tratamento de dados nesses cenários, consulte as orientações sobre privacidade e dados de aviso.

Escolha a execução pelo risco da mudança

Use este ramo de decisão para escolher o próximo passo, sem misturar o resultado incremental com a aceitação de lançamento:

• Se o arquivo alterado e o teste têm uma relação que o runner identifica, então rode bun test --changed com a referência correta e guarde a lista de testes selecionados.
• Se a mudança envolve configuração, geração de arquivo, carregamento dinâmico ou montagem de dependências, então não dependa apenas da seleção incremental; execute explicitamente os testes de integração do fluxo afetado.
• Se o teste selecionado verifica somente o template ou o envio simulado, então trate o resultado como evidência de lógica da aplicação, não como prova de recebimento.
• Se o critério de aceite exige confirmação de leitura em uma caixa, então faça uma verificação externa controlada e registre o destino, o conteúdo esperado e a associação com a execução.
• Se não houver uma evidência verificável para uma dessas etapas, então informe a lacuna no relatório e não marque a etapa correspondente como aprovada.

Esse fluxo evita duas conclusões excessivas: “o teste passou, logo a entrega funciona” e “o teste não apareceu, logo o Bun está com defeito”. A primeira ignora a fronteira entre mock e entrega; a segunda ignora a possibilidade de o teste não estar conectado aos arquivos alterados, de a referência estar errada ou de a tarefa executada não ser a que a equipe imaginava.

Faça o CI mostrar a cobertura que realmente executou

Teste incremental e tarefa de lançamento têm objetivos diferentes. O primeiro pode oferecer retorno rápido após uma alteração; o segundo deve cobrir os caminhos que a equipe definiu como essenciais para aceitar a versão. Se o pipeline roda apenas bun test --changed, uma falha de seleção pode deixar uma regressão importante fora daquela execução sem que o processo necessariamente falhe.

Revise o comando real do CI, e não apenas o script local. Confira a versão do Bun instalada, a referência passada ao comando, o checkout feito pelo job e os testes que aparecem no relatório. Guarde essas informações junto ao resultado do pipeline. Se houver etapas distintas, mantenha nomes claros, por exemplo: testes incrementais, integração de cadastro e verificação de e-mail, e validação de recebimento controlado. O nome de uma etapa precisa corresponder ao que ela de fato executa.

A execução completa do conjunto de testes pode ser necessária para uma verificação de lançamento, mas não substitui o teste externo quando o requisito é comprovar que uma mensagem chegou ao destino. Do mesmo modo, uma verificação de recebimento isolada não prova que os outros comportamentos da aplicação foram testados. Defina a cobertura conforme o risco e mantenha cada evidência vinculada à sua própria etapa.

Se a alteração de template entrar no diff, mas o relatório não listar um teste que verifique o conteúdo, trate isso como uma lacuna a investigar. Se um teste de integração estiver no relatório, confira quais partes do fluxo ele percorre e quais componentes simula. Se o pipeline confirmar recebimento, assegure que a mensagem observada pertence à execução atual, e não a uma tentativa anterior que permaneceu no destino. Para comparar opções de teste com caixa real e endereço principal, veja também e-mail descartável ou endereço pessoal.

Valide o recebimento em um ambiente controlado

Use um endereço isolado para testar o produto que você desenvolve ou tem autorização para avaliar. Não use esse processo para criar contas em serviços de terceiros sem autorização. Mantenha a caixa de teste separada de correspondências pessoais e evite colocar dados reais de clientes nos campos de cadastro. Assim, uma falha de template ou um envio repetido não contamina o endereço de trabalho nem expõe informações desnecessárias.

Um procedimento reproduzível pode seguir estas etapas:

1. Identifique a alteração. Registre os arquivos modificados e a referência usada na comparação do Git. Separe template, lógica de cadastro, montagem do link e processamento da verificação.
2. Inspecione a seleção incremental. Execute bun test --changed com a mesma referência planejada para o CI. Guarde a saída e confirme se os testes relevantes aparecem.
3. Rode os testes críticos diretamente. Se o teste não foi selecionado, ou se existe dependência indireta, execute explicitamente os arquivos ou a tarefa de integração que cobre o fluxo. Não edite a relação de importação só para fazer o teste aparecer sem confirmar que ela representa a arquitetura real.
4. Confira as asserções. Verifique o conteúdo da mensagem, o link ou código, as condições de validade e a mudança esperada no estado da conta. Se o teste usa um mock, documente que essa parte não confirma entrega.
5. Faça a verificação de recebimento quando ela for requisito. Use um destino controlado, procure a mensagem associada à execução atual e confira se o conteúdo esperado está acessível. Não transforme a falta de mensagem em diagnóstico automático de uma causa única: verifique também a configuração e o resultado reportado pela aplicação.
6. Registre os limites do resultado. Informe separadamente quais testes foram selecionados, quais passaram, qual parte do fluxo foi exercitada e se houve confirmação de recebimento. Se uma etapa não foi feita, marque-a como não verificada.
7. Repita a verificação no CI pertinente. Confirme que o job usou a mesma referência, executou a tarefa esperada e publicou a lista de testes. Uma execução local não prova que o pipeline recebeu a mesma configuração.

Esse procedimento transforma uma impressão de cobertura em uma trilha de evidências. Também torna mais fácil distinguir uma falha de seleção de uma falha de lógica ou de uma mensagem não encontrada no destino, sem atribuir ao runner capacidades que ele não oferece.

Quando um endereço temporário ajuda — e quando não ajuda

Para um teste pontual de cadastro, recuperação ou verificação do seu próprio produto, um endereço temporário pode manter a correspondência de teste separada da caixa principal. A escolha faz sentido quando o objetivo é consultar uma mensagem de teste, evitar misturar notificações de desenvolvimento com e-mails pessoais e manter os dados do cenário sob controle. As orientações sobre uso de uma caixa temporária para testes ajudam a avaliar esse tipo de cenário.

Isso não substitui uma conta de teste persistente quando o fluxo depende de acesso continuado, respostas posteriores ou recuperação confiável. Para contas financeiras, governamentais ou outros serviços importantes, um endereço descartável não é uma opção apropriada para cadastro ou recuperação. E, em um pipeline, não presuma que o endereço temporário tenha integração com Bun: o runner seleciona e executa testes; o processo de consulta à caixa é uma etapa separada, que precisa ser configurada e verificada por você.

Ao usar o Inboxonce para uma conferência pontual, avalie a caixa como uma forma de consultar uma mensagem de teste, não como prova automática de que o CI executou a regressão correta nem de que qualquer mensagem será entregue. Se você precisa saber apenas se o template e o estado da conta estão corretos, testes locais ou de integração podem bastar. Se precisa confirmar que uma mensagem do seu próprio fluxo ficou legível em um destino controlado, um endereço temporário pode ser uma opção para essa etapa; mantenha separados o registro do runner, o resultado da aplicação e a evidência de recebimento.