mailtrap-sticker-111-150x150

Mailtrap: Save your customers from getting test emails.

| 4 Comments

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.

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!

Try Mailtrap right now! We hope you’ll like it and waiting for your feedback at support@mailtrap.io

Share
* Railsware is a premium software development consulting company, focused on delivering great web and mobile applications. Learn more about us.
  • Jan Hettich

    I love this concept in principle. But what assurance do I have that my customers’ email addresses and potentially confidential content of the emails we’re testing are secure? Can the emails be deleted securely? Any possibility of making the software available to run on our own server?

    • Pavel Pavlovsky

      Hi Jan,

      Thanks for using mailtrap!
      On confidential content – please check terms of service here: http://mailtrap.io/pages/tos
      By clicking “Clear” on your mailbox – all mails with your customers e-mail data will be removed.

      We may discuss running dedicated service (likely with database on your side and code on ours). Drop us details on support@mailtrap.io

  • http://www.lowpricelessons.com/ Richard Curran – LPL

    Thank you very much, I’ve been using MailTrap for the last couple of days and it is just what I was looking for. 

    I was looking for a way to see the output of mails using rake commands, I had so much generated data in there that just blandly loading the html wasn’t cutting it. Reading it from the terminal whilst running it in the console is a rubbish solution. Actually sending the mail is an attractive option but I don’t want to spam myself. I don’t want to fill up my computer by outputting mail to a file. 

    MailTrap was the perfect solution for me, cheers.

  • Heidi Lobecker

    We have been successfully using MailTrap to ensure our email subscription and notification system is working for our upgraded application. Q: Is there a way I can use MailTrap to REPLY to a message? We have functionality that creates discussion posts from email replies and I’d like to test that.

    Thank you,
    Heidi

Want to get more of Railsware blog?

RSS FEED

We're always ready to help!

CONTACT US