Email fake para testes: endereços seguros para formulários de cadastro
Se você cria ou testa sites, passa o dia digitando endereços de email em formulários. A única coisa que não pode acontecer é uma mensagem de teste ir parar na caixa de entrada real de um desconhecido. Esta página mostra qual email fake usar em cada tipo de teste — e quando a mensagem precisa chegar de verdade.
Primeiro decida se a mensagem precisa chegar
Essa única pergunta decide tudo, e vale fazê-la em voz alta, porque a resposta é “não” mais vezes do que se imagina.
| O que você está testando | A mensagem precisa chegar? | Use |
|---|---|---|
| Validação, armazenamento ou exibição de um endereço | não | um domínio reservado — veja abaixo |
| O fluxo de confirmação, à mão | sim | uma caixa daqui |
| O fluxo de confirmação, automatizado | sim, legível por código | um serviço com API |
| Teste de carga ou de volume | não — e não deve | um domínio reservado, sempre |
Quando a mensagem não deve chegar: use nomes reservados
Existem domínios feitos exatamente para isso, com garantia de nunca pertencerem a ninguém: example.com e os irmãos example.net e example.org, reservados pelo RFC 2606, mais toda a terminação .test.
Endereços neles são a resposta certa para dados de exemplo, dados iniciais e testes de carga. Nada do que você enviar consegue chegar a uma pessoa, porque não há ninguém lá — por acordo internacional, não por sorte.
test@mycompanytest.com acaba sendo o domínio real de alguém com frequência suficiente para importar, e um teste de carga apontado para ele não se distingue de um ataque. Os nomes reservados não custam nada e eliminam toda essa categoria de acidente.Quando a mensagem precisa chegar, à mão
Pegue um endereço daqui, rode o fluxo e leia o que a sua aplicação realmente enviou — cabeçalhos, links e como a mensagem aparece quando não é o seu próprio cliente de email que a mostra. Duas coisas que isso pega e um capturador de email local não pega:
- A entrega real. A mensagem percorre um caminho de email real, então um remetente mal configurado falha aqui, e não em produção.
- Como um estranho a vê. Links que só funcionam na sua sessão, imagens que nunca carregam, um link de descadastro apontando para localhost — tudo aparece na hora.
Se a sua aplicação envia arquivos, preste atenção também aos avisos de anexo: são os mesmos avisos que os seus usuários vão ver.
Quando precisa ser automatizado
Raspar a página no lugar disso é um mau negócio mesmo quando funciona: é frágil, não documentado e é exatamente o tipo de tráfego que acaba sendo bloqueado.
Testando os caminhos de recusa
As falhas interessantes não são “um endereço válido funciona”. Vale cobrir:
- Um endereço num domínio sem registro MX — a entrega falha sem que o endereço esteja malformado. O seu código deveria distinguir uma coisa da outra. Veja qual é qual.
- Um domínio internacionalizado, tanto em Unicode quanto na forma
xn--. A maioria dos validadores recusa uma e aceita a outra, e geralmente do jeito errado — conversor. - Variações do Gmail com pontos e com mais. Se a sua checagem de unicidade compara as strings como vieram, uma pessoa pode registrar contas sem limite. Normalize primeiro — aquela página faz exatamente o que a sua checagem deveria fazer.
- Uma parte local muito longa. O padrão permite 64 caracteres; muitos formulários cortam em silêncio em 20 e guardam algo que já não leva a lugar nenhum.
Algo para construir, não para testar
Se o seu produto não aceita endereços de email fake, recuse-os com clareza. “Email inválido” para um endereço perfeitamente válido é o erro mais confuso do gênero: o usuário confere a grafia, digita de novo e recebe a mesma mensagem. “Não aceitamos endereços de email fake” ocupa o mesmo espaço e acaba com a confusão.