My build machine has been very useful in running unit tests for the various components of the project I'm working on, but having recently spent several days trying to integrate a couple of components to run on a clean machine, I realised that unit testing isn't enough. There were three components that I wanted to use on a clean machine:

• the file watcher service, that monitors a directory for XML files and kicks off...
  
• the XSLT engine, which converts the XML into a different format and
• the import component, which reads the converted XML and inserts the data into SQL Server

These components all have passing unit tests that are automatically run a couple of times a day. There are, by definition, no unit tests that run the three components together. So today I wrote an MSBuild task to automate the integration testing of these components. There was a little pre-work, like creating a merge module for each component, and an installer, and tweaking the configuration files that are installed by default. (Annoyingly, we're still using Beta 2 of .NET, so there's no MSBuilding the .vdproj files yet.)

The MSBuild task took about 3 hours to write and perfect, and in order:

• Checks that the relevant directories exist, and test files are present
  
• Counts the rows in the destination SQL Server table
• Copies some test files in the watched directory
• Waits a few seconds
• Counts the rows in the destination table again
• Makes sure that the correct number of rows have been inserted

Creating an MSBuild task is really straightforward. Derive a class from Task, add some public properties, and code the stuff. For some slightly more technical details, see Barry Dorrans' presentation and code samples from the last DeveloperDeveloperDeveloper event.

I then created a new MSBuild project file, which:

• Runs the installer (silently)
• Starts the file watcher service
• Runs the integration test task
  
• Stops the file watcher service
• Uninstalls it all again
  

This worked beautifully, so I added it at the end of the main build script using an MSBuild task. So now I have integration testing running on the daily build machine.

I've just finished reading In Code: A mathematical Journey; a very interesting book about cryptography, written by a 16 year old girl who invented a new algorithm. I didn't know very much at all about cryptography before reading it, but now I've got much more of a feel for it. I could just about follow what was going on in the book, but not enough to really understand it all. It was a great read though, and I so recommend it to you.

One of the purposes of having a build machine is to eliminate the "Well it works on my machine" problem. The build failed this morning. A developer was using a COM DLL, and had installed from the component-monger's installer, and then copied the DLL to the lib folder and checked it in, which is fine.

The build failed because the DLL wasn't registered on the build machine. Adding the regsvr32 call to the pre-build event in the project meant that the DLL was registered before the project was compiled. The build machine is now completing successfully again.

After a bit of digging around, I found that

Path.IsPathRooted(directoryName)

can be used to check whether a directory path is absolute or relative in .NET.

I've just received an email from a recruiter advertising an open day for a company based in Epsom. It looks good and everything, but the recruiter didn't consider one important thing; I worked there for over 3 years.

The next Sussex geek dinner will be on 4th January 2006, at the Highlands in Uckfield. I thought just after Christmas would be better than trying to squeeze one in between Christmas parties and things. Please let me know if you'll be coming.

There'll be some more free Stormhoek, and Nick, one of their representatives, has asked to come along to meet us.