Flow, Interruptions and Gold-Titanium Alloys

As I mentioned earlier, I've just had a very productive and fun weekend of hacking on testresources. But why was it so good?

Fast Commits

Because I was working offline using Bazaar, I could make commits to testresources and they'd be done before I could Alt-Tab back to Emacs.

Fast Tests

It takes about 0.15 seconds to run the test suite. This meant I was running it all the time, which in turn meant that I was totally certain about whether the code worked all the time.

Clarity of Purpose

I knew where I was and where I wanted to go.

No Rabbit Holes

The testresources code base is small enough that it is nearly impossible to get distracted by other systemic defects. If there is such a defect, it's probably the one that you're working on right now. This might be another way of saying...

No Blockers

I wasn't waiting on anyone to do anything. There weren't any other bugs that needed to get fixed before I could continue.

No Integration

The system is about as self-contained as it gets. No signals, subprocesses or sockets: just Python. The only dependency is pyunit3k, which is small, robust, well-tested and also pretty darn self-contained.

No Interruptions

I wasn't answering questions on IRC, taking Skype calls, handling incoming email, doing the washing, checking Facebook, catching up on my blogs, watching a film or wrestling a bear. "Fast Commits" and "Fast Tests" probably fall into this category too.

In other words:

There is nothing except this. There's no art opening, no charity, nothing to sign. There's the next mission, and nothing else.

testresources: fresh blood

Last weekend I spent a bunch of timing hacking on testresources with Rob over at Chris's place. testresources is an extension to unittest that allows tests to specify the resources they use declaratively, so that these resources can be cleanly shared between tests. On Saturday, we talked a bit about direction and decided on some goals. On Sunday, I got busy.

The idea isn't particularly new: zope.testing has had "layers" for a long time. The key differences between testresources and Zope layers are:

• You can use more than one TestResource. You can only use one layer. Allowing tests to specify many resources makes it easier to use only the resources that you need, which in turn makes for a faster test suite.
  
• A test that uses testresources can be used independently of other testresources machinery. With layers, you pretty much need the whole shebang. This means that you can use testresources with trial, bzr, nose, tribunal or unittest.TextTestRunner.
  
• Layers have magical inheritance stuff. testresources has no magic.
• Layers do some work in subprocesses to accommodate some setUps that can have no tearDown. testresources doesn't know what a process is.
  

That said, I'm mainly familiar with layers from Zope 3.2—they may have changed since then.

testresources itself is somewhat old. Rob hacked up the first version about three years ago and little has happened to it since. I've always agreed with the approach, but have also had a few qualms about implementation details that made me reluctant to use it or to recommend it. Now, it's well on its way to being something that I can trust and perhaps, love.

If you are interested, check out my branch or at least flick through the TODO file.