a view from afar

I just came across a need to test emails sent in a Rails project. It's a RSpec story integration test I'm working on (using Selenium, not a RailsStory), and using ActionMailer in test mode is not good enough. Instead I'm using Matt Mower's handy tool Mailtrap

I created a listener class to start and stop mailtrap as the story runs - which is easy enough - but I needed something to parse the log file from Mailtrap. So I created Mailtrap::LogParser - code available here for anyone that's interested.

As soon as github gives me a beta login, I will fork the Mailtrap repo and add this in. For the mean time, you can use the tarball above.

This is just a stopgap solution really, until Mailtrap has a way of outputting a more structured (and therefore easily-parseable) output.

Recently (last few months) I've had the opportunity to show two developers some BDD techniques. The first was in Ruby, using RSpec (new URL!), the second was in C# using MbUnit and Rhino Mocks. Here are my observations about the process. This is quite a long post, and strays a bit into the technical details that can become obstacles to teaching BDD, but I decided to include as much as possible to emphasise just how tough I found it.

Drop this into your Rakefile and let the heckling begin!

Between me and the helpful folk at rspec-users, I managed to come up with a solution to specify that a gem is loaded and used in a library. This is for the case where you don't want the gem loaded all the time, or where you can put the loading in a method called at some point (as opposed to just at the top of a file) - although I'm sure it could be adapted.

Now, it is a widely known fact, among possibly half of my six subscribers, that I'm working on an ORM and database migration package for Rubyists that will kick ActiveRecord into the floor. Not that I don't have some respect for the library - it has, after all, seriously raised the bar in terms of user (ie webapp developer) simplicity. But it suffers some serious architectural faults, and has begun to outgrow the spirit of the ActiveRecord pattern (obligatory Fowler link). I am not the only person who thinks so either, some people such as Matthew at PlayLouder are far more frustrated than me.

After a discussion today on rspec-users, I confirmed that it would be nice if you could structure specs like this, to break your behaviour descriptions down into related groups:

1
2
3
4
5
6
7
8
9
10
11

describe MyClass do
  facet "my_method" do
    it "should do this" 
    
    facet "some stuff" do
      it "should do that"
    end
  end
  
  it "should do the other"
end