Like the new skin?

Couldn't help myself. Blogger.com has added a ton of new features.

[Listening to: Adema - Freaking Out]

Moving from NUnit to MbUnit -- here goes nothing

With some encouragement from my first ever Blog Comment (thank you Jonathan) I'm trying to convert from NUnit to MbUnit. I figure I'd document as I go.

Having dropped the latest version of MbUnit onto my VPC I figure I'd load some existing assemblies to see what happens when using the MbUnit GUI against an NUnit assembly.

First, add an assembly. Hang on... no menus. I had a brain-blip. For a second or two (I hope it was only that long) I couldn't figure out just what to do. Thankfully my well trained right-mouse-button-index-finger jumped in and pulled me out of my haze. Of course, the context menu. Where was I again? [Is it time for my pudding?]

Oh, yes, adding assemblies. Adding my previously compiled assembly gave me a security exception. I guess this isn't too much of a surprise as I'm developing as a non-admin. In particular it was a security error from Microsoft.ApplicationBlocks.ExceptionManagement trying to access the registry. Cool thing is, this error "went away." Okay so I cheated. I ran the app as an admin, then I ran as my user again.

Running a second time I get a different error (progress, no?) It's a System.BadImageFormatException. I know this one. Since I'm running the .NET 1.1 binary on a Whidbey/CTP2005/.NET 2.0 machine it tips over. I can deal with that. Just as the following line to the MbUnit.GUI.exe.config
        <supportedRuntime version="v2.0.40301" />

Okay, third times a charm right. Not quite. The app runs. Adding assemblies appears to be working but nothing happens. Running tests does nothing. Removing assemblies does nothing.

Let's try recompiling with MbUnit...

First removing all references to NUnit.Framework; easy enough.
Add references to MbUnit.Framework.dll. You'll need MbUnit.Core.dll too.
Replace using NUnit.Framework; with using MbUnit.Framework; (for TestFixtureAttrbite a.k.a [TestFixture]) AND using MbUnit.Core.Framework; (for TestAttribute a.k.a [Test])

This probably would've been all that's required except that I have some custom NUnit type assert code for things that NUnit missed like AreEqual methods for System.Xml and System.Xml.XPath. So for that there were a bunch of code changes required. I can't help but notice the MbUnit.Core.Framework.Xml namespace. Perchange my custom stuff can go by-by?

BTW: If you aren't using Lutz Roeders amazing .NET Reflector why don't you? Developing in .NET with it is like a kybrd wtht vwls.

So far, so good. I have an assembly.

WooHoo. I'm able to run the tests. A few aren't working, but hey, I changed some code and replace the whole unit testing framework. 2 failures out of 64 tests isn't too bad (I'll look at those later.)

There's a few hiccups with the GUI (loading multiple assemblies caused some grief) but it mostly worked. And the HTML report is sweeet. Once I get the kinks ironed out I'll post again.

That's all for now. Got to get some sleep for my day job. Sigh.

[Listening to: Rob Zombie - Return of the Phantom Stranger]

Composite Unit Testing with MbUnit

Jonathan de Halleux uses MBUnit for Composite Unit Testing. I so have to try this.

I originally saw this in a CodeProject article. It seemed almost useful then (no offence Jonathan) but it didn't click until now. I'll let you know how it goes.

Beware File.OpenWrite

I can just see me falling for this. CraigBlog - Beware File.OpenWrite. Courtesy of Craig Andera

Exclusive read access to MSMQs

Jeff Key gives tips on
exclusive read access to an MSMQ queue. This might be useful.

New version of SnippetCompiler

Via the Larkware Daily Grind there is a new version of Jeff Key's awesome SnippetCompiler App

Whoo boy it's been a while

As you can tell it's been a while since my last blog (not counting my shameless plug for some free software.)

As sad as it is to admit, the "real world" interfered with my plans. Neo where are you when I need you.

A lot's happened since I last worked on anything. Primarily, Whidbey has been released in a couple flavours. First the PDC bits, then, more recently, the VS 2005 Community Tech Preview. I figured it would be an excellent opportunity to use the next version of the tools and start HookUp over again. Let's face it, at the pace I'm going I'll hit version 1.0 right around the time that VS 2020 comes out.

This also provides an opportunity to start a "proper" Test Driven Development (TDD) project. I've done a fair amount with NUnit while pretending to do TDD, but to be honest it was more of a TSAABOCIWD approach (Test Sometime After A Bunch Of Code Is Written Development.)

I plan to hook in NUnit from the start. Also I will be making use of FxCop which is currently at version 1.30. There's no better time to start.

Following the advice of a number of blogs I've avoided SourceSafe this time. I played briefly with Subversion and TortoiseSVN with limited success. After a few dozen pages of docs I got my heirarchy set up and was starting to get accustomed to the environment when I corrupted my database. Not a great start. It's a crying shame too, the integration was nice.

So, instead, I switched to Vault. It appealed to me for a couple reasons: 1) it's a commercial product, so hopefully is more stable (fingers are crossed.) 2) it's free for single users. The drawback I see is the need for a SQL server. Since I'm running the Whidbey stuff in a VPC instance the extra cycles for SQL server hurt a bit.

I'll leave it there for now. Wish me luck

[Listening to: Puddle of Mudd - Bring me Down]

Free defect tracker from Axosoft

Axosoft is offering bloggers a free 3-user version of their .NET & SQL based OnTime defect tracking software (bug tracking software). For more information, visit http://www.axosoft.com/Free3UserOffer.htm.

How can I resist?

Paradigm shift

Not really a paradigm shift, but fixing my kludgy start. I've gone down the very non-OO approach of large switch statements to control flow:

switch (node.Name)
{
case "BinaryProcessor":
m_Blocks.Add (new Processors.BinaryProcessor());
break;

case "Parser":
m_Blocks.Add (new Parsers.Parser());
break;

case "Processor":
m_Blocks.Add (new Processors.Processor());
break;
//...
}


This thing of beauty had a fraternal twin elsewhere in the code:

object curData = ...;
string str;
byte[] bytes;

if (block is Parsers.IParser)
{
((Parsers.IParser)block).Parse ((byte[])curData, out str);
curData = str;
}
else if (block is Renderers.IRenderer)
{
((Renderers.IRenderer)block).Render ((string)curData, out bytes);
curData = bytes;
}
else if (block is Processors.IBinaryProcessor)
{
((Processors.IBinaryProcessor)block).Process ((byte[])curData, out bytes);
curData = bytes;
}
//...


Eeeewwww. Even as I was typing this I was shaking my head. You know how it goes though. First it's just 1 case or if just to make sure you don't slip in something nasty. Then it becomes 2 -- it's soo much easier than OO-ing the code. Laziness kicks in and Shazam! you end up with spaghetti. Just today I found myself seeing if unions were supported in .NET which finally snapped me out of it.

It's now time to do this properly.

I have to admit it was somewhat nostalgic cutting "university-code" again. All I need is to sprinkle a few printf(""); here and there to "make it work".

Some useful tools

I just found some very useful tools that I figure I should share. In truth I can't take credit for finding any of them on my own as I just grabbed them from the sources indicated below, but here they are anyway:

Jeff Key's Snippet Compiler Util (from Tim Sneath's Blog)

NUnit integration for Visual Studio.NET (from Scott Hanselman's Blog)

Code<Template>.NET (from CP)