Tracks uses a Trac for a bug tracker, and the awesome Tracks community helpfully attaches patches to tickets for a committer (me) to review and apply. I wanted an easy way to do this, so I whipped up this rake task that let’s you select a ticket and attachment to apply to the app as a patch:

Here’s a sample shell session demonstrating the case when there is more than one patch attached:

$ rake trac:patch
Enter the ticket number: 560
There are multiple attachments for this ticket.
[1] cleanup_stats_controler.diff (25.9 kB) - added by foo@barcom on 09/16/07 19:32:35. - cleanup of stats_controller
[2] cleanup_stats_controler.2.diff (25.9 kB) - added by foo@barcom on 09/16/07 19:46:51. - whoeps old patch introduced an error. fixed with this patch
Which number attachment do you want to use as the patch to apply: 2
Patched with cleanup_stats_controler.2.diff from Trac ticket 560.

If there is only one attachment, it will be applied without you having to make a selection. Also, you can specify the ticket number on the command line (i.e. rake trac:patch TICKET=155).

Coming up soon, I’ll be attending the first RubyEast near Philadelphia on September 28. I’ll spend some time with the Oxygen team promoting Ript at the DigitalLife Expo in NYC September 27th-30th, and will be taking my first trip to Austin to participate in the ALT.net Conference October 5th-7th.

Unfortunately, it looks like I’m going to be out of town for XP Day Manhattan on October 13th.

Selenium, the web testing framework, is powerful tool for your testing toolbox. I use it extensively on Tracks to nail down pesky AJAX bugs. Yesterday, I hit a wall that took a few hours to overcome. Once I did, though, I had a new level of appreciation for how expressive I can be with Selenium and Selenium on Rails.

This was the situation: in Tracks, you can add a new “to-do” specifying a “context” that it is associated with. The to-do is added to the page within the corresponding context container via AJAX. If a brand new context is specified, the app should create a new context container to hold the new to-do. That was the behavior I needed to test.

We’re looking at the contents of a .rsel file, called RSelenese, which is translated to a Selenium test by the Selenium on Rails plugin. The lines I had trouble with were 4, 8 and 9. I had never used this feature of Selenium before, and had trouble figuring out that to execute javascript in the context of the page under test, I had to use the this.browserbot.getCurrentWindow() reference.

In a nutshell, the test simulates a login, loads the homepage, gets the current number of context containers on the page and stores it in a javascript variable, stores that number plus 1 in another variable, adds a new to-do to a non-existent context, and then waits to make sure that the new number of contexts is equal to one more than the original number.

I was satisfied that I got this working, but disappointed with how ugly the syntax was. There had to be a better way…

It turned out that Selenium had an extensions model that could help. Selenium looks for a file called user-extensions.js and loads it automatically. I created one like this:

To get at it elegantly from Selenium on Rails, I followed the pattern the plugin uses in defining methods to call the built-in commands. To avoid modifying the plugin code directly, I reopened the module SeleniumOnRails::TestBuilderAccessors in my own selenium_helper.rb in my app’s lib directory. (I “require” this file in my config/environments/test.rb).