A sometimes tricky and always mundane element of developing web applications is testing email workflows such as account registration or invitation. In this post I will go over some strategies for using disposable email to do just that.
Email Workflows
Almost universally, online identities are tied to one of three things: an email address, an already verified account (e.g. Facebook or Google), or increasingly, an SMS-enabled phone number. If you sign up for a new account using an email address, nine times out of ten you will be required to verify that you in fact control the address you want to register before gaining access to the new service. This usually involves clicking a link embedded in an email sent to the address in question. Assuming the registration workflow for your application follows this pattern (which it should) then you may be wondering how you can test it end-to-end.
What Makes This Hard?
In our scenario, the email address is our unique identifier for a user. That means we can’t register with the same address more than once. One easy but not scalable solution for testing is to use many addresses you have access to. In a development environment, it’s likely that you won’t actually be sending emails over an SMTP transport. Rather, you’ll probably use a dummy SMTP server such as SubEtha or FakeSMTP.
What you really want to test in this environment is that your code triggers a message to be sent to an SMTP service. Even if you were sending real emails, it would be easy in such an environment to destroy and re-create the user database so that you could reuse email addresses. But what about in a QA or Production environment where you don’t have that luxury? How can you test that your code triggers the message to be sent and that the message gets delivered to a real mailbox? Does your webapp send emails? How do you know if it’s working?
Use A Disposable Email Service
A more robust solution to this problem is to use a disposable email service such as Mailinator or Guerrilla Mail. You can send email to any address hosted at these services and then manually check that inbox to see if your mail arrived. You can append the date or timestamp (depending on your testing frequency), in order to ensure the uniqueness of your address. In case you need it, Guerrilla Mail also allows you to send emails.
It’s important to note that Mailinator inboxes are public and accessible to anyone. And even though they purge messages after every few hours, it’s still not a good idea to send private information to them.
Automate
There are also ways you can get access to an API for one of the many disposable email services. From what I’ve seen, Mailtrap appears to be the leader in that space. When you have recommendations from Wes Bos and customers like Atlassian and Github, that’s a really good sign you’re doing something well. Using an API will allow you to programmatically check for the delivery of your email to a mailbox within their service. For a small monthly fee you can upgrade your service to provide up to 60 inboxes and a real email address per inbox that you setup. But, if you’re cheap like me, it would also be relatively easy to setup an end-to-end test using a tool like Nightmare which could access a Mailinator inbox and inspect the page for the existence of your email.
Conclusion
Testing end-to-end email workflows can be difficult and is definitely not exciting. Luckily, disposable email services are around to make it a lot easier to verify functionality and a lot easier to scale. Hopefully you are able to adapt these services to work for you, too.
Ross – great article. You should get a Mailinator trial. In addition to realtime email delivery and an API, you get every inbox (millions, not just 60) in an entire domain all wildcard searchable in one dashboard.