We're hiring!

We're actively seeking developers and designers for our Detroit & Ann Arbor locations.

Testing Email Templates in Rails

Sending email from a Ruby on Rails application is easy. Sending well-formed and aesthetically-pleasing HTML emails that render reliably in all mail clients is rather more difficult.

The code/test/edit cycle can be greatly eased by a number of great tools such as mail_view or MailCatcher, but in the end there’s no substitute for actually trying your email templates. There are a lot of differences in HTML handling across email clients, so testing your emails is critical.

Here’s an approach to email template testing that I’ve found useful.

Testing Rails Email Templates

1. Get a real SMTP server.

It’s possible to set one up on your development machine if you like, or your company may have one. If you don’t want to go through that setup effort, consider a commercial service like SendGrid. They have a trial level that allows enough deliveries for most development purposes.

2. Configure your development environment to send real emails.

This should be fairly straightforward, and you probably have configuration code for your production environment that you can copy and update. Here’s a piece of my config/environments/development.rb:

ActionMailer::Base.smtp_settings = {
  user_name: "my-user",
  password: "my-password",
  address: "smtp.sendgrid.net",
  port: 587
config.action_mailer.delivery_method = :whitelist_proxy
config.action_mailer.whitelist_proxy_settings = {
  delivery_method: :smtp,
  domain: %w|atomicobject.com|

You’ll note that I am using the whitelist-mail-proxy rubygem. This gem (as its name implies) allows me to whitelist which email domains will receive the real mail. This way I can blast out as many emails as I like and can be confident they’re not going out to real users.

3. Enable Rails’ helpers.

At this point you should be able to send out emails, but we’re not quite done. We need to set the default host name for links and for asset paths in order for Rails’ helpers to be able to work and to generate the correct urls. Try adding this configuration snippet to your environment:

ip_address = UDPSocket.open {|s| s.connect("", 1); s.addr.last}
config.action_mailer.default_url_options = { :host => "#{ip_address}:3000" }
config.action_mailer.asset_host = "http://#{ip_address}:3000"

This code, from coderrr, asks your operating system to route a UDP packet out to Google and captures the sending IP address (yours), but doesn’t actually send any data. Essentially, this lets us autodetect your address on the local network. Rails’ helpers will use that address in links and asset paths, so when you send mail from your development machine, the recipient will be able to see images hosted off your machine and follow links to that application instance. Since the IP address is detected, any new developer that picks up the project will automatically use paths correct to his machine.

I’m sure there are cases for odd networks, and this trick won’t work if the email client is outside your network, but for most cases this should let you send an email from your development machine, walk over to a machine with Outlook, and see what it looks like.

Other Rails Email Design & Testing Tools

There are a lot of tools out there that can help you design better mails. I’ve successfully used actionmailer_inline_css to automatically copy styles directly into the HTML (needed for GMail). MailChimp has tools to help design mails, and though I haven’t used it, Fractal purports to be able to automatically implement workarounds for some known client quirks.

What techniques have you used to make developing email templates less painful?

Mike Swieton (40 Posts)

I live and work in Grand Rapids (or near enough as to make no difference).

I write software – all kinds of software. I’ve written code for worldwide enterprises and startups. I’ve build for the web, for desktop, mobile, and everything in between. I’ve worked in all sorts of different industries and with all sorts of technologies.

I always try to understand whatever I’m working on deeply no matter the subject, for anything from learning about shoulder anatomy (… what a mess that is) for weight training, to investigating using the ideal gas law when working with chocolate in a whipping siphon, or diving into a vendor’s source code to find out what’s wrong.

This entry was posted in Ruby on Rails and tagged , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.