Re: Enforcing a Build and Test Policy

In a previous entry I posted some code that would run unit tests after every successful build. I used ‘Register for COM Interop’ and a ‘ComRegisterFunction’ attribute. Ian Griffiths asks, “What does this add that you don't get with VS.NET 2003's build events?” You can think of this as running lower level build events. Instead of executing a batch file and passing it an assembly location, you’re executing a method and passing it a Type object. It also means you can create logic that will run as part of installation. If these unit tests don’t pass, then fail early and don’t even install!

There are a couple of unsatisfactory features of the technique you've proposed here. First, it leaves cruft in the registry - it will register your TestBeforeRegistering class as a COM class under the ProgID SampleTests. (And it will make up a CLSID. I think if you ever change your TestBeforeRegistering class it may make up a different CLSID, causing an ever-increasing amount of registry cruft to accumulate.) [Ian Griffiths]

I don’t think it will leave cruft in the registry because before the next registration it will be unregistered. Certainly if you abandoned the project it would leave cruft behind. But I don’t think one more orphaned CLSID would be too much of an issue.

Second, the way that errors are handled is distinctly unsatisfactory. [Ian Griffiths]

Unfortunately there isn’t an easy way to output a more appropriate build failure message. There is a way, but I won’t go into that now. ;o) For the moment I just run Chris Szurgot's Trace Monitor in the background and pick up the exception that way. BTW if you’re not using Trace Monitor, you should be!

I've been tring to find usage descriptions for the NUnit.Core routine. TestSuiteBuilder, TestSuite, etc. Where did (do) you find them? [K. Carter]

Intellisense and Reflector I’m afraid.. ;o)