How to test email flows when building software

1st Feb 2023

Share this article:

Nearly all software sends emails to the end users at some point: think password reset emails, thank you emails, receipts, notifications.

When you're building and testing software you need a solution for "faking" the email sending part of your software. That way you can test that emails get sent at the right time, that they're content is great and that they'll actually get delivered. Using a real email service and limiting yourself to only your own email address while building is an option but not a great idea. You don't want to accidentally send test emails to real people. Just ask HBO:

Picture of Tweet from HBO apologising for mass email

What features do you want from email testing?

We hinted at a few of the things that you want above but here's some basic ideas (in order of importance):

  • To reduce the risk of spamming real people
  • To test that emails get triggered at the right time
  • To enable testers to test use cases that include engaging with email content
  • To enable QA to review email content
  • To check that the "deliverability" of the email is good
  • To require minimal, or no, code change between test and production environments

What are your options for email testing?

Assuming you're sending your emails using plain old SMTP you have essentially 4 options: don't use SMTP, use a machine local service, host an SMTP server or use a 3rd party service.

If you're not using SMTP to send your emails (maybe you're using an API provided by your email service) then often these services will have some sort of test mode. Usually, though, they're not the best!

Don't use SMTP

A simple way of satisfying the top few features is to not send emails at all in development/test. Instead, you could simply save the email content to a database or the file system and then provide some interface for viewing those "emails". It can be a pretty quick way of doing things (we've done it ourselves) but it requires a completely different code path so doesn't test the actual sending and requires the creation and maintenance of the code for sending and viewing.

Use a machine local service

If you're a developer, one of the easiest things to do is to set up a local service on your PC that provides an SMTP server and some UI to view the emails.

You set up the service, point your SMTP settings at localhost and then you're away.

That's not bad when you're working on your own but pretty useless when you want to share your software with others (like client testers) who don't have access to your machine.

Also, we're yet to see what that looks ok!

Here's an example: FakeSMTP

Self hosted SMTP server

So the obvious solution to supporting people not on your local machine is to host the SMTP server yourself in somewhere that's reachable by everyone testing the software. That could be on your company LAN or hosted on the internet somewhere for access from anywhere.

Your main problem with doing this yourself is that it's generally not a core part of your application, can be expensive and difficult to maintain overtime.

However, if you have strict privacy requirements it may be the only option.

3rd party service

What is nearly always the best option is to simply use a 3rd party email testing service. They're generally more feature complete than you get build yourself, it's their core business and, frankly, they're pretty cheap to use.

They will nearly always provide you with SMTP credentials to send your emails to (so just a config change to your code) and will then provide a web-based UI for reading the emails that you've sent.

The other beauty of 3rd party services is that you can configure all of your 3rd party services to send their emails through them as well. For example, we use Auth0 for our authentication. When we want to test our sign up processes we want Auth0 to send their emails through Imitate Email. Thankfully, Auth0 provide the ability to configure their SMTP settings. See our Auth0 on Imitate Email guide for more information.

How does Imitate Email fair?

Obviously, we run Imitate Email to support just these scenarios. It's completely free to get started as a solo developer but supports large teams for companies that require testing across teams/clients/projects.

Where we differ from other companies is that we focus on developer/tester experience of the email testing. Our embedded web widget can be placed inside your application as you build/test it so that you don't have to switch back and forth between your software and the email testing software. On top of that, using our single sign on technology, you can allow 3rd party testers access to your email testing without having to provision, or pay for, an account in Imitate Email.

To find out more, and to see a demo, visit our website