We assume you’re a web developer, QA engineer, product manager, etc — somebody who’s doing internet software projects. Have you ever needed to test e-mail notifications in your web application? Today we’ll speak about common issues while testing e-mail notifications and best solutions for that issues.
Common issues with manual e-mail notifications testing
We believe most critical issue here is accidentally sending dummy e-mails to real customers while testing web applications at staging/development servers. But let’s start with easier once at first.
Let’s say you’re doing users registration where every new users gets registration confirmation e-mail. In order to register yet another user for testing purposes you need to have new unique email address that should be registered somewhere. That’ll become problematic unless you’ll use service like Mailinator which seems good enough as a solution for our problem.
Now let’s make things a bit harder. Imagine our web application became successful and now we need to send weekly e-mail notifications to our users: a bit different for different users. How will you test that to know which e-mails were sent to which customers? Will you create tons of virtual users with tons of mail boxes and check each one? But that’s just so stupid and time-consuming!
In real life things are even worse. In my experience it is usually a good idea to copy production database to your staging servers or development machines for test purposes — so you’ll work with a real data instead of something synthetic. But this also brings you a risk of sending test e-mails to the real customers from your development/staging environment. My personal score is about 2500 e-mails sent by mistake at a time. I know people whose personal record is more than 2 millions emails sent by mistake! Share your personal fuck up stories in comments ;)
Existing solutions for keeping your customers from test e-mails
If you’re lazy or just don’t have enough time, you may skip this chapter and just scroll down to Mailtrap: our solution to common problem because our solution is really much better that others, believe me!
So which possible solutions are most popular?
- Tweaking up your SMTP server, so it’ll send all messages based on specific rules, for example will rewrite recipient e-mail address to yours one. We used this solution for sending all e-mails to whole development team for one of our projects. It was fine but there was just one problem: each team member got tens to hundreds e-mails in his mailbox each time our QA engineers checked new application release. And what if you don’t have access to SMTP server settings?
- Stripping customer e-mails from your test database with a special script, etc. In this case you’ll still need to have lots of test mailboxes which is quite a drawback, but you’ll be safe: real customers won’t get test e-mails from you.
- Use dummy SMTP servers that’ll save all e-mails messages locally instead of sending them. Mailcatcher is a good example of such tool for Ruby. You can easily find same tools built with PHP, Python, etc. One major disadvantage on all of these tools is that they’re assumed to work on developer’s machine (so you can access that saved e-mails anytime), not on the staging servers where most non-developers test application functionality.
- Some teams even prefer hardcoding different application logic for different environments. For example application will send e-mails normally from production servers but will forward it to special e-mail addresses for all e-mails other that @your-domain.com. This solution may be more flexible than previous 3 but also harder to implement and support.
As you can see each solution have major disadvantages. That’s the reason we’ve created an alternative one called Mailtrap.
Mailtrap: our solution to common problem
Mailtrap is a standardized solution aimed to help development teams to build and debug their email delivery functionality: it substitutes your SMTP server and allows viewing all your e-mails online at Mailtrap site, forward them to your normal mailbox if needed.
So how does it work? You get Mailtrap’s SMTP credentials after registration. Than all you need to do is placing those credentials (hostname, port, login and password) to your application’s configuration (for non-production environments)… and Voilà — your e-mails sending is isolated from real users but still available to view and forward!
Ruby on Rails setup example.
config.action_mailer.smtp_settings = {
:address => 'mailtrap.io',
:port => 2525,
:user_name => 'box52',
:password => '133632a53ddfec53a4b05496f7296a60'
}No local daemons setup, no tweaks on your staging server, no application-level modifications — just change 4 lines of code, that’s it!
Since Mailtrap uses standard SMTP protocol it is cross-platform: you’re able use it with any platform on any programming language.
All e-mails are now available to view at mailtrap.io. Each e-mail has unique URL — so you can share it with your team members with no problem while creating new bug tickets in your issue tracker, for example.
For some cases we have alternative solution(for example, you’d like to see how your e-mail messages look in specific mail client): you can forward a message to specific e-mail address directly from Mailtrap’s web interface.
Are there any bells and whistles there?
Yes, here is a quick list of current Mailtrap features:
- Ability to access ANY e-mail without registration
- Sharing e-mail by copy’n’pasting its URL
- Developer tools for debugging & improving email templates which include HTML syntax highlighter, message source code view, CSS reseting.
- Access to messages history.
And yes, it is completely free!