Tatva-Artha

ActionMailer classes, for sending out emails, typically reside with models, inside app/models folder. Yet, they have traits that are similar to controllers. For example, each actionmailer class has a view folder inside app/views where email templates are defined. And testing support for email is provided as functional tests with assert_select macros such as assert_select_email.

In my current project, most of our email hooks are defined on model classes as after_filter. This is in line with recommendation to keep controllers thin and models fat. However, testing email body’s html format is a pain since assert_select_email support is only available in ActionController::TestCase hierarchy, and not in ActionMailer::TestCase hierarchy.

Consider following ActionMailer test:

class MortgageBorrowerEmailerTest < ActionMailer::TestCase
  should "invite borrowers" do
    realtor, borrower = User.make, User.make
    response = MortgageBorrowerEmailer.deliver_invite_borrowers(realtor, borrower)
    # test from/to/subject works now :-)
    assert_same_elements([borrower.email], response.to)
    assert_equal([realtor.email], response.from)
    assert_equal("#{realtor.full_name} has invited you to manage your mortgage application in Lendable", response.subject)
    # testing body is still primitive :-(
    assert response.body.include?(realtor.full_name)
    assert response.body.include?("/account_preferences/#{borrower.perishable_token}/edit")
  end
end

ActionMailer::TestCase has decent support for intercepting mail delivery and hold onto mails for introspection. This allows us to assert smaller pieces like from, to, subject etc. However, what it doesn’t support is more fine grained assertion on email’s html body. it would be nice to be able to apply assert_select assertion on email’s response body for critical pieces of information that needs to be present in an email.

So, I dug into ActionController::TestCase’s assert_select_email to see how I can duplicate it for my unit test. Here is what the original method looks like:

# [rails]/actionpack/lib/action_controller/assertions/selector_assertions.rb
module ActionController::Assertions::SelectorAssertions
  def assert_select_email(&block)
    deliveries = ActionMailer::Base.deliveries
    assert !deliveries.empty?, "No e-mail in delivery list"
    for delivery in deliveries
      for part in delivery.parts
        if part["Content-Type"].to_s =~ /^text\/html\W/
          root = HTML::Document.new(part.body).root
          assert_select root, ":root", &block
        end
      end
    end
  end
end

As this implementation depicts, it is interesting to see how easy it is to take any html code snipped and create an HTML::Document out of it so that assert_select can be applied to it. Anyway, the default implementation for assert_select_email assumed multipart email with one or more parts in it. Since my email are simplistic text/html rendered as email body, I hacked to get what I needed. As follows:

class MortgageBorrowerEmailerTest < ActionMailer::TestCase
  include ActionController::Assertions::SelectorAssertions
  def assert_select_with_string(html_text, &block)
    root = HTML::Document.new(html_text).root
    assert_select root, ":root", &block
  end
end

With this in place, I could now take my email response’s body and assert-select on it:

    should "share mortgage with existing client" do
      ...
      assert_select_with_string(response.body) do
        assert_select "h1", :text => "Greetings from Lendable"
        assert_select "tr#sender_identity td strong", :text => @realtor.full_name
        assert_select "tr#rate_search_criteria" do
          assert_select ".purchase_price"
          assert_select ".loan_amount"
        end
        assert_select "tr#rate_info td a[href=?]", "http://#{DEFAULT_HOST}/rate_selections/#{@rate_selection.id}",
          :text => "#{@rate.program.type_and_term} Mortgage at #{number_with_precision(@rate.rate, :precision => 3)}% from #{@rate.program.lender.name}"
      end
    end

As we can imagine, this assert_select_with_string() can be useful in testing helper methods that return html snippets. I am not sure what the downside is for testing email body format as unit test vs. funcational test but I am happy that I can test it in isolation as unit test.

Do you know of any?

Yes, we did. And here’s why.

I was at a recent social gathering where we started talking about how funny and bizzare it is that people use twitter to post messages like .. sh**, woke up late .. having lunch at Gino’s East … driving to work … my dog peed on my bed … . .. Oh ok, that last one is probably out of thin air but posting those kinds of messages probably don’t add much value for anybody, the author or the readers.

To test the waters, I created an account about 6 months ago. Very quickly I realized that twitter fills in a void that none of the other communication tools do.

Keep in touch, I mean real touch:
We don’t make it a point to write email to every single one on our list of 200 or 500 contacts every once in a while. Why? Because you will have to walk down the list, write to each person individually. We would have to come up with something to talk about that this person might be interested in. Too much work. But we still want to peek into their life and vice versa to find out if there is anything that interests both of us. Twitter fits the bill. You tweet (by definition, short) about anything that touches your life. If the other person is interested in you, he/she will follow you and vaguely peruse over your tweets. You do the same and follow him. Even if you no longer meet each other (because one of you has moved to different city or different job), you can talk to each other over this channel. If everybody in my group did this, I’d be fully aware of what happens with them on a day by day, hour by hour basis without actually calling them up. And vice versa.

Another great advantage that isn’t apparent at first is that twitter allows me to follow person who I am not associated with directly but what he does has a large impact on my life. Since I am programming in Ruby these days, I want to know what ruby gurus (@dhh, @wycats) are upto each day. If you are a java programmer, you may want to follow RodJohnson. These guys (I thank them) tweet few times a day and knowing that DHH and his team is upto each day is huge… it is gold mine!

Mass conversation:
Twittering is like sitting at a bar with folks that share your interests and talk about interesting things, just that it happens in a very loosely coupled way. All the same conversation rules apply. You want to be having light and funny yet intelligent conversation without having to invest the time to walk to a bar. And you can be in multiple bars at the same time. It doesn’t replace the bar meetups but it does make it easier to have more of those in our daily life, a good thing isn’t it.

You are never alone, even when you are alone:
We always had internet to keep us busy surfing and killing time when alone. One problem with plain vanilla internet surfing is that you have manually visit several websites to dig relevant pieces out that are important to you. Twitter makes it easier to subscribe to channels (people or companies or search tags) that are relevant and in very short message bursts gives you lots of superficial information. This is great for quickly perusing on channels and then dig deeper into stuff that interests you. With twitter account and a smartphone, those 5 minute wait at bus station, 10 minute wait at restaurant could be good investment in keeping in touch.

Books, Articles, Blogs and now Twitter:
We couldn’t write books every month, so we started writing articles. We couldn’t write articles each week, so we invented blogs. We can’t write blogs every day, so we have twitter. It is just a very low cost way to get the message across.

After using it for a while here are some things I learnt as far as twitter etiquettes are concerned:

Keep audience engaged:
My leg is hurting … nice weather … are boring tweets. They don’t initiate interesting conversation. Instead what I’ve found useful is to post an opinion on some news you just heard. Or some article, blog that you came across or commenting on a live TV cast of Presidents’ speech. Ask quick yes/no type questions although not always. Talk about pair programming .. how about twitting a quick question to you programmer colleague on how to solve a pesky problem? beat that!

Post often but not too often:
Posting 15, 20, 30 tweets a day on an account is good. Anything more is annoyance and you run the risk of loosing your followers. Posting less isn’t good either. It isn’t blog or article after all. Its purpose is to keep in touch … how about a tweet an hour on average.

Have separate accounts:
You need separate accounts to match each of your personalities. By personalities, I mean you are a professional at work, music rockstar in your school circle and lazy bum in your family circle. Sometimes the differences in these personalities are so stark that you don’t want to mix those. For example, my mom and sister will have no interest what so ever in my ruby programming tweets. However, my colleague at work aren’t really interested (much) in my hindi movie reviews and cricket fan club conversations. Having separate accounts keeps things simple.

All in all, the concept of twitting is here to stay!

Certainly, a great innovation. Does twitter.com hold a patent for this