On the Mark: 2/13/2003

	Thursday, February 13, 2003

Losing Little Gray Cells I am really embarrassed to admit this. While working on a prototype project (using .NET) I wrote some code to tear apart an objects and write it out to the file system. I did the same to reconstitute the object from the file system. This was all completed and tested a few weeks ago. It wasn't anything hard, but in retrospect it was a dumb thing to do. You see, until this morning I had completely forgotten that this is exactly what serialization does for you. In other words, I wasted time writing unneccessary code.

The sad part is that I know about serialization. I've used it on Java projects. I thought it was great compared to some of the custom marshalers I had written for COM objects. I even new about .NET's serialization support. Gee, I've even written code using .NET's serialization. So how did I forget about it this time? Am I losing my mind, or do I simply have far too many tools and capabilities at my disposal to remember all of them? I'm a little scared.

3:39:44 PM

The early Nunit review: *** (of four). I like this tool. Nunit makes it simple to set up and execute a test harness without being intrusive on your code base. That's important because I want don't want the hassle of writing a separate executable to house test code. I also don't want to have to rip out pieces of test code or toggle back and forth between different start-up objects (one for testing, one for debugging).

Using Nunit is easy. Just write test harness classes and mark them with the [TestFixture] attribute. Within each test class write methods marked with Nunit's [Test] attribute. Nunit provides a variety of assertion methods for validating test post-conditions. Use these to enable Nunit to keep track of successful and failed tests. Compile the code and let Nunit take over. Once pointed to your assembly the Nunit application uses .NET's reflection features to find the test harness classes and methods and execute them.

Tips

Set up a new folder/namespace for test classes. while not required, it simplifies project organization and will make it easy to pull out the test code later.
Use setup methods, marked with the [SetUp] attribute to factor out common initialization code to be run before all of the test harnesses.
I'm writing a test class for each business object, but there is nothing to prevent you from creating a single test harness class for multiple objects.

I've got more exploring to do, but so far this looks pretty promising.
2:56:27 PM

I want to take a look at Microsoft's TaskView example, but I am a little busy at the moment. Maybe I can come back to it in a week or two. My top priorities at the moment are: 1. Find a project I can land on; 2. Find projects for my teammates; 3. Try Nunit on my Business Rules Sandbox project.
10:17:29 AM