Super curioso Pedro! Você chegou a rodar algum teste automatizado lá dentro? Por exemplo, rodar o npm test? Pois como esse comando irá rodar os testes de integração, ele vai enviar emails de verdade, mas que serão enviados para o STMP local de teste que é o MailCatcher do projeto.
E os testes vão randomizar os nomes de usuários, emails e coisas assim usando o faker.js.
Nossa, não acredito! Esqueci completamente disso hahaha Eu realmente rodei os testes mas os endereços de email parecem tão reais que nem pensei nessa possibilidade. A biblioteca faker.js é muito boa.
Mas então pra rodar os testes eu tenho que retirar as variáveis de ambiente do mailtrap?
Porque mesmo com oMailCatcherrodando ele envia pro mailtrap.
Resolvi testar isso aí em cima e realmente no modo de teste ele usa as varáveis padrão. Já que no módulo de email já faz uma verificação pra ver está em development ou test poderia mudar também essas variáveis, adicionando
(transporterConfiguration.host = "localhost"),
(transporterConfiguration.port = 1025),
na linha 16, o que acha?
Opa, tem um ponto que eu não entendi. Pela visão do TabNews, o "mailtrap" dele é o MailCatcher. Ou seja, em localhost, todo email que sair do servidor será enviado para o MailCatcher e deveria apenas ser listado lá, na interface web dele na porta 1080 se eu não me engano.
Esse não está sendo o comportamento com você?
É que quando as variáveis apontam pra outro servidor de email alguns testes falham porque não conseguem acessar os emails recebidos.
Mas pensando melhor não faz tanta diferença porque não tem muito sentido colocar variáveis de produção (no meu caso o mailtrap) em ambiente de teste/desenvolvimento.
Ah entendi o que estava querendo fazer. De fato, se num ambiente de testes você colocar variávies de ambiente de produção e rodar a bateria de testes, as coisas vão se atravessar 🤝