Mandrill is an email service, now part of MailChimp, designed for sending transactional email. It's designed for sending one-to-one e-commerce emails and automated transactional emails like user notifications, password reset emails etc.
What does Mandrill provide?
Mandrill primarily provides an API for creating, sending and tracking transactional email. Alongside that, there is a web app to let users manage the email sent through that API. High level features include:
- API/SMTP
- Templating engine
- Email tracking
- Deliverability reporting
How does it help with testing email flows
Mandrill is pretty good when it comes to testing your transactional email. They provide "test" API keys which you can use to send emails to a "test sandbox" and then view those emails inside their web app. It enables you to make only a config level change to your code to switch between real email sending and fake email sending.
Where does it lack for testing?
While Mandrill is quick to get set up with testing it does not lend itself too well to testing of the content or to enabling user testing across teams.
Specifically, there is no validation of the email HTML, no tools to help with device testing or checking that emails will be delivered through spam filters, for example.
In terms of team dynamics, if you want your testers or clients to view test emails you need to give them access to Mandrill via their own user accounts. This is difficult to manage but, also, does not provide access controls in order to restrict what they can see to only the emails that apply to them.
What's the alternative?
There's a few alternatives for improving your email testing when using Mandrill:
- Create your own email client through the Mandrill API
- Mock out the API completely in your code
- Use a 3rd party tool
Create your own email client
As Mandrill provides a comprehensive API, you can make use of it to create your own web UI over the top. You can then keep the Test API Key secret so that the key is not exposed to other members of your team or clients.
Pros
You don't have to change your email sending code as you're still using the Mandrill API for sending email, albeit in test mode.
Cons
You have to build and maintain an entirely separate application that is not part of your core business. So, it's also expensive to do this.
Mock out the API completely
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.
Pros
Very simple to implement (assuming you're happy with a simple result)
Cons
As above, You have to build and maintain an entirely separate application that is not part of your core business. Even worse, you're not testing your email sending code during testing/development. It's also expensive to do this.
Use a 3rd party tool like Imitate Email
Imitate Email is a 3rd party email testing tool that's hosted in the cloud and is designed to make testing email flows, and content, amazing.
In the context of Mandrill, Imitate Email provides a Mandrill compatible API allowing you to send emails using your standard Mandrill client but then provides a load of tools that Mandrill does not.
For example, Imitate Email provides tools to help with your responsive email design, spam checking tools to help with deliverability but also provides an embedded web widget which makes testing email flows as you build, or your clients test, your app really great.
To get started with testing Mandrill via Imitate Email is pretty simple. Firstly, make sure you've signed up to Imitate Email.
The only code change required is to modify your Mandrill client library so that it sends requests to Imitate Email instead of Mandrill. All of Mandrill's endpoints are at https://mandrillapp.com/api/1.0. For Imitate Email, send the requests to https://imitate.email/mandrill/api/1.0 instead.
You will also need to send us credentials for your requests (so we know who you are) by changing the key property that you send in your Mandrill requests. That way your email sending code stays the same - you just send the requests to a different host and use a different API Key.
For a personal mailbox, you can find the key in Settings → My Mailbox and then clicking the link at the bottom of the page.
For a team mailbox, go the projects page and click the icon next to the mailbox you want to send email to.
Imitate Email takes testing one step further by integrating with Mandrill's templating engine. If you make use of templates in Mandrill you can provide Imitate Email with an API key so that Mandrill can render your emails as they would be in Mandrill. For more details on setting that up see [/docs#mandrill](the docs).
To find out more, and to see a demo, visit our website