Luke Melia

I’ve been contributing code to an open source project called Tracks. It’s a web-based tool that helps people implement the Getting Things Done system (previously mentioned here).

The application is written in Ruby on Rails, a delightful framework for building web apps that is making waves in the web development world. One of the things I enjoy most about helping with the project is getting to learn more about Rails. As a result of this knowledge gained, I recently completed my first paid Rails freelance project. That was a great feeling!

So, the news this weekend is that there is a new version of Tracks out, 1.04. I’m confident that the release will be exciting for some people. It’s interesting to note that from my perspective, a release is kind of a non-event. I’ve been working with the latest code base all along, so tagging some code as a release doesn’t really change too much.

Simon Phipps looks at this the phenomenon of the different perspectives held by the contributors to an open source project and the users of the project:

I think “open source” is like this too. The “glass” divides software deployers and software developers. One side of the glass it’s all about participating in a community of code, innovating, contributing and other developer issues. The other side of the glass it’s all about value-for-money, freedom of choice of supplier, low exit costs and other business issues.

I certainly use a whole lot more open source software than I contribute to, so I can look from both sides of the glass. I do think that having the experience of contributing to a project changes the way you behave as a user of other projects — you’re more appreciative and more helpful. Kind of like a restaurant patron who has had the experience of working as a waiter/waitress tends to be a kinder, gentler, better-tipping diner.

As I think about it, I guess the release does matter to me — it means more people will be interacting with my code every day. And that’s awesome!

Here are the steps I followed to install a local copy of subversion on a shared hosting account at pair.com. You should use the latest release of subversion, which you can link to from here. At the time of this writing, that was 1.3.0.

user@machine% mkdir src
user@machine% cd src
user@machine% wget http://subversion.tigris.org/downloads/subversion-1.3.0.tar.gz
user@machine% tar -xzvf subversion-1.3.0.tar.gz
user@machine% cd subversion-1.3.0
user@machine% ./configure --prefix=$HOME --without-berkeley-db --with-zlib --with-ssl
user@machine% make
user@machine% make install

You will want to make sure that $HOME/bin is part of your PATH, too. You may need to run

user@machine% rehash

to get your shell session to see svn.

That’s it! May your commits be prodigious and your updates clean…

This entry is going to document how we separated our unit tests from our integration tests using MbUnit, NAnt, and TestDriven.NET. In detail!

At work, we've recently kicked into full-on Test Driven Development. We're loving it. Our tool stack as it relates to TDD is as follows:

• Visual Studio 2005
• MbUnit
• TestDriven.NET
• CruiseControl.NET
• NAnt

As we wrote tests, we distinguished between unit tests, which exercise a particular class or small group of classes, and integration tests, which cross application layers and may require a locally installed copy of the system under test to execute properly. Our objective was to have unit tests run during continuous integration and during the TDD process, but not have the integration tests run unless we specifically request it.

MbUnit supports a [FixtureCategory(string category)] attribute on a TestFixture (i.e. class). It seemed reasonable that each TestFixture should contain either unit tests or integration tests, but not both, so we made sure that was true and applied FixtureCategory attributes to every TestFixture in our test assemblies. For example:

The next step was to get our build script capable of targeting the type of test we want to run. This can be accomplished by specifying the /filter-category:category flag in the call to mbunit.cons.exe. The relevant targets in my NAnt file ended up looking like this:

That worked nicely, and I made sure that the targets called under CruiseControl .NET include "unit-test" and do not include "integration-test".

The next problem was a little more daunting, though. We had mapped a keyboard shortcut to telling the TestDriven.NET plugin to run tests. (We chose F6.) This functionality isi vital to our TDD process. We can hit F6 inside of a test method to run that particular test, inside of a fixture to run all tests in the fixture, inside of a namespace to run all tests in that namespace, and finally, on a project in the Visual Studio Solution Explorer to run all tests in that assembly. It's vital to the TDD process that these test runs be fast. I really wanted only unit tests to be run, and not integration tests.

After a little googling and reflectoring later, I knew that TestDriven .NET looks at a registry key to find registered TestRunners, and picks the appropriate TestRunner for the context that has the lowest priority. After installing TestDriven .NET and MbUnit the registry key [HKEY_CURRENT_USER\Software\MutantDesign\TestDriven.NET\TestRunners] had the following child keys:

I set out to create an assembly that could be pointed at from this registry key and contained an implementation of ITestRunner that only ran test fixtures that had a FixtureCategory attribute equal to "unit".

It turns out that we can accomplish that without too much code by extending the MbUnit test runner, which is open source. (I really wish TestDriven .NET were open source, but that's beside the point for the time being...) So I created a new Visual Studio solution with a single project: "OxyMbUnit.AddIn." I updated the properties page to specify the assembly name and default namespace both to be "Oxygen.MbUnit.AddIn" and specified a keyfile to give the assembly a strong name.

You'll also need references to the MbUnit.Addin, MbUnit.Framework and TestDriven.Framework assemblies.

Then I added a single class: "OxyMbUnitTestRunner.cs"

Note how we're passing a CategoryFixtureFilter to the base class' Run(...) method. That's all it takes!

Note that the third method (besides RunAssembly and RunNamespace) that is defined as part of the ITestRunner interface is RunMember, which refers to a specific fixture or test. We'll leave our base class' implementation to handle that. If a test or fixture is explcitly selected, we want TestDriven .NET to run it, even if it is an integration test.

Once we have that assembly building, all we need is the registry entry to force TestDriven .NET to prefer this TestRunner for MbUnit-based test assemblies over the one that ships with MbUnit. It should look something like this:

The @="5" ensures that this TestRunner will have priority over the standard MbUnitTestRunner, which has a value of 10. After setting up this key manually and moving the built assembly to C:\Program Files\OxyMbUnitTestRunner, I fired up Visual Studio and verified that the TestRunner was working as expected. Cool!

Realizing that manual registry and Program Files directory installs are a drag, my colleague Sebastian whipped up a WiX file to build an installer for our TestRunner. Here's the source to the WiX file:

And there you have it. Happy TDD days are here again!