Edd Dumbill's Weblog: 'ruby' articles

Telling stories with RSpec

2008-01-12T13:49:42Z

For a while now I've been writing RSpec specifications to test Expectnation, rather than "traditional" Rails unit tests. Although I don't completely get the Behaviour Driven Development hype around RSpec, I do find that it helps in writing more literate and maintainable test suites.

Until very recently, however, RSpec for Rails had no decent answer to Rails' integration tests. Integration tests enable the testing of compete scenarios, as opposed to the specific testing of methods or single HTTP operations that unit and functional testing provide.

For instance, our integration test suite for Expectnation tests things such as "a user tries to submit a proposal, is redirected to the account sign up page, signs up, and then is redirected to the proposal submission page". This involves multiple steps, and the whole suite of tests necessitates a lot of reuse.

The need for reuse resulted in trying to construct a DSL-like set of methods for each step, such as "user logs in with email X and password Y". It has gotten a bit tangled, especially when looking at test failures to see what's really gone wrong.

After a while, unravelling the test suite starts to feel like unpacking Christmas lights. (Photo: shoothead)

RSpec Story Framework

My problems with integration tests made the Story Framework, newly available in RSpec 1.1, look very interesting. Based around plain text descriptions of application behaviour, it lets you write integration tests with good reuse and good diagnostic reporting.

For example, here's a story I wrote to check the login process.

Story: login as an existing user
        As an unauthenticated user
        I want to log in to Expectnation
        So I can see my account details

        Scenario: login details are correct
                Given an event provider
                And my test@example.org account
                When I log in with email test@example.org and password foofoo
                Then I will be logged in
                And I will be shown the account page

The words such as "Given", "When" and "Then" are cues to the story runner to execute some code. Behind the story sits a collection of steps. Here's a couple of steps from this test:

Given "my $email account" do |email|
    @user = find_or_create_user_by_email({:email => email,
      :password => 'foofoo',
      :password_confirmation => 'foofoo'})
end

When "I log in with email $email and
                         password $password" do |email, password|
    post '/user/account/authenticate',
      :user => {:email => email, :password => password}
end

Notice how a clever bit of string matching allows you to pass parameters from the story prose.

With a small bit of bolting together, the prose stories are then run as code and the tests executed. One nice touch is that if you write a story which doesn't yet have code behind it, it is marked not as a pass or fail, but as pending, which means you can sit down and write all your stories and then get to coding the steps later. This beats writing empty tests which transparently pass.

To conclude, the RSpec Story Framework offers these advantages over Rails' integration tests:

Text-only stories makes it very easy to write and understand tests
The construction of steps for each line makes it easy and maintainable to construct reusable components for the tests

GObject subclassing in Ruby

2006-01-31T20:23:24Z

Thanks to everybody who wrote in with suggestions following on from my initial Ruby GNOME investigations yesterday.

After talking at cross purposes for some time in a bug report with a Ruby GNOME developer, I was pointed to a good example of how to do what I wanted: subclassing a GObject in Ruby.

This is something that the Mono Gtk# bindings do so well, I'd forgotten the required mechanics. Here's a simple subclass of button. I've highlighted the required magic in bold.

class MyButton < Gtk::Button
   attr_accessor :hitcount
   # tell the GLib object system this is a new type
   type_register
 
   def initialize(text)
     super("label" => text)
     self.hitcount = 0
   end
 
   # rather than overriding 'clicked', we must
   # override the signal_do_clicked method
   def signal_do_clicked(*args)
     self.hitcount+=1
     super
   end
 end

The type_register call registers the new class with the GLib type system (something the Mono bindings do for you automatically). The second key was knowing the name of the default signal handler, which turns out to be of the form signal_do_signalname.

So, to follow up yesterday, I hadn't found a bug, merely a gap in the documentation. Thanks to Masao Mutoh for taking the time to answer my questions.

For comparison, here's the same implementation in Gtk#. There are pros and cons of both languages. Ruby's succinct attr_accessor is balanced by the neat GObject-aware subclassing and the constructor inheritance of C#.

class MyButton : Button {
        private int hitcount;

        public MyButton (string text) : base (text)
        {
                hitcount = 0;
        }

        protected override void OnClicked ()
        {
                hitcount++;
                base.OnClicked ();
        }

        public int HitCount {
                get
                {
                        return hitcount;
                }
                set
                {
                        hitcount = value;
                }
        }
}

Join the conversation about this post

Beginnings with Ruby GNOME

2006-01-31T02:37:24Z

A while back I started porting the GTK examples from Mono: A Developer's Notebook to IronPython and Boo, the results of which are available in my Subversion repository.

Although I've not finished that task yet, I thought I'd investigate the state of the Ruby GNOME bindings by porting those same examples. They have the advantage of increasing gently in complexity.

Before I go on, you can find the work in progress posted in the ruby-gnome/monodn branch of my Subversion repository.

Now for a few observations. At the basic level, Ruby GNOME has a lot in common with all the other GNOME bindings out there. One distinguishing feature however is signal handlers, which take a Ruby closure as an argument. Look at this handler for closing the window, for example:

w = Gtk::Window.new("My Window")
w.signal_connect("delete_event") { Gtk.main_quit }

This is fine for simple handlers. Developers wanting to reuse handlers might wish to specify a method here to use. The best way of doing this I've found is:

def my_handler(but)
     ...
end
 
button.signal_connect("changed", &method(:my_handler))

This involves a little bit more magic, as you can see.

I've also run into an unexpected barrier with subclassing and the class default signal handler. The subclassing example from the Mono Notebook shows an example of overriding the clicked method of a Button. In C# this looks like this:

class MyButton : Button {
 ...
 protected override void OnClicked ()
 {
    hitcount++;
    base.OnClicked ();
 }

In Ruby I would write this:

class MyButton < Gtk::Button
 ...
 def clicked
   self.hitcount += 1
   super
 end

However, when you click the button it's clear the overridden method isn't being called. I've filed a bug with what I think is the underlying problem. In this instance, I worked round it by adding a signal handler in the constructor:

self.signal_connect("clicked") { |b| b.hitcount += 1 }

At the moment it feels like I'm writing rather C-like Ruby, rather than it being idiomatic. But then again, I am porting examples from C# in as literal manner as possible, in order to facilitate comparison.

Join the conversation about this post

Why Rails?

2006-01-21T22:50:53Z

When I moved this blog from being Zope-backed to using Rails several people got in touch to ask why. This is a brief explanation of why I've moved.

Firstly I should point out I've had a long and mostly happy experience with Zope. I got into Zope originally because I'd spent some time in constructing web frameworks from scratch (we're talking 1995-1999 here) and found that not only does a framework need good templating, it needs reusable components within that.

Zope seemed like a good fit, so I spent some time getting up to speed and was happy there. However, there were some things that didn't make me feel completely comfortable. Zope offered a very stark choice between developing through the web based interface (DTML methods, etc.) and writing raw Python. To do really useful stuff, you had to get into the Python side of things, but also learn a lot about Zope guts that wasn't really well documented.

I spent more time than I probably should have had to reading Zope's own source code in order to figure out how things worked. Fine, for my own silly little projects, but not practical in general. It was hard to get the overall view of a project, and hard to test. The learning curve was a little too steep, I suppose.

So, once I'd got to a certain point I stopped, and looked around for a platform that gave me more code visibility and testability. Loyal readers will know I've looked at ASP.NET and Python, Quixote and Cheetah. ASP.NET I rejected because I didn't view Mono's web application server as mature enough at the time, and I also had reservations about ASP.NET's non-free baggage. Python, Quixote and Cheetah looked a lot more friendly.

What I wrote about Quixote and Cheetah at the time was "this combination isn't adequately presented and described anywhere." These were good technologies, but not integrated as a framework. I started work on integrating them, and made some interesting progress. I was correct that Python lacked a solid modern framework, and the time was certainly right for it, as we can now see by the emergence of Django and TurboGears.

However, at the same time I started looking at Rails and found out that it did pretty much what I wanted. To be honest, I'd avoided it for a while as a friend once did me the disservice of calling Ruby a cross between Python and Perl. "Why ruin Python?", I thought. And it takes me a while to get over the hype barrier before I conclude that there's a "there" there.

Now I've been using Rails for a while, I find its attractions have changed for me. The thrill of not having to write basic functionality over and over again has given way to more select pleasures. Writing in Ruby itself is a rewarding experience, as its idioms become plainer over time.

Sure, you can write Java or Perl in any language, and that's where I started off. But the subtle elegance of the Ruby idiom is a slowly appreciated and highly satisfying flavour. For developers who consider themselves as poets and artists too, I can't think of a better language.

Join the conversation about this post

Edd Dumbill's Weblog: 'ruby' articles

Telling stories with RSpec

RSpec Story Framework

Further reading

GObject subclassing in Ruby

Beginnings with Ruby GNOME

Why Rails?