No, I'm not joining Palantir (well hopefully for dinner), but I'll be attending the Taxonomy Sprint organised by the Encyclopedia of Life at the Field Museum in Chicago this week.

Taxonomy was the reason I installed Drupal 4.5.x back in 2005 (I wanted to categorise articles by author AND subject and none of the previous 4-5 CMSes I'd used could do it, oh those heady days), and while it's a very powerful system, it hasn't received a great deal of love the past 4-5 years. So when you're running up to 2 million terms through it, it starts to creak.

I'm still trying to get caught up after Drupalcon Szeged and sitting in a terminal in Minneapolis in between flights, so my laundry list of things I'd like to change about the taxonomy module won't make it into this post, but I'll try to post updates throughout the week.

As of today, after months of work, all core tests pass.

This means you should be able to download HEAD, install it, enable simpletest module, run all tests from admin/build/testing and see zero failures. If you can't, post a bug report, please.

By no means does this mean HEAD is bug free - we have about 65% code coverage (much of that implicit rather than explicit), and we actually removed two valid tests where they'd been committed without a correlating patch fixing the bug itself. So this is just the beginning of automated testing in core, and where the work really ramps up to make it an indispensable development tool.

The massive, massive advantage to a 100% pass rate is it's going to become much, much easier to spot regressions when patches are committed to core. In fact if we use the tests properly, we'll be able to stop the vast majority of regressions from getting committed at all. Less regressions means shorter code freeze, means longer code thaw!!

At a minimum, running all tests with a patch applied should become standard practice when doing reviews, and you can always check http://testing.drupal.org/tests to see what it thinks too. That means no patch gets to RTBC (or stays at needs review long) which breaks a test. Got it? ;)

At the moment, tests are only going to catch a percentage of regressions. While they'll never be a panacea to clicking around yourself, and can't tell you if the interface is ugly or the code style is terrible, or measure performance etc., it's a very good first line of defence. We need to ensure that core tests are as comprehensive and robust as possible, since while they're a good first line of defense, 64% coverage is reminiscent of the Maginot line.

To do this, three things need to happen:

1. Write lots of tests to fill in the gaps in core coverage.
2. Get testing.drupal.org working, so it'll sweep the issue queue, test if patches apply, run all tests, and mark issues to code needs work if they fail so we don't have to (my wrists will thank it).
3. Write tests to accompany existing bug fixes and feature requests in the issue queue, to confirm they work properly, and help get them committed more expediently.

So if you haven't got started with the whole testing thing yet, there really is no excuse any more.

Since tests for Drupal 7 keep breaking unexpectedly, I started doing test snapshots every few days to track progress. After the first two runs there's good and bad news - less tests fail each time, but they're often different ones. Getting to a 100% pass rate is a pre-requisite for encouraging more people to write tests and extending the Drupal 7 release cycle, so hopefully we'll get the remaining ones fixed up pretty soon.