Very interesting post on CraigBlog about the limitations of Test Driven Design.
Interesting comment on you've been haacked

I'm a funny guy. No, seriously.
I pay attention when the security experts advise: "Don't run as Administrator."
So I don't, I run as a normal user {not even a power user}.

So why the hell it is so bloody hard to do so?
There are many places where I've to get out of my way to make my setup work. One instance is VS.Net add-ins, a complete mystery all on itself.

Another, apperantely is Google Desktop.
Like most software I use, I install as administrator, and use as a normal user, so why, oh why do I get this error message?
"Google Desktop Search can only run when the user who installed it is logged in."
This is a killer bug for me, and the main reason why I unistalled Google Desktop.
There is a little page about it in the support section.

In this day and age, there is no reason for this. This is simply stupid.

Another things that irks me, why does it index my computer if the computer is idle for more than 30 seconds? That is insanely long time in computer terms.
When I work on the computer, I rarely leave it untouch for longer then 30 seconds, which means that Google Desktop will not run until I leave the computer.
This is broken.

This is a test of WB Editor capabilities.
The previous post was posted using ::w.bloggar:: but I won't be using that (no WYSIWYG, and it messed up my title).

WB Editor  also just overwrote a half-finished post of mine when I explored the interface. Bad application, Bad!

But so far, this seems to be the only flaw in it.

TestDriven.Net is finally working!
Jamie Cansdale sat with me through Messanger for quite a while before we managed to make it work, but now I can use it to run tests.
The experiance is so much better then running the command line... :-)

Highly recommended, and you won't get better support anywhere.

The problem was one of those strange stuff that you won't find anywhere else:
I could install as admin, and it would work, only as long as I used it as admin.
I couldn't use it as a nomral user (my usualy mode of operation).
I couldn't install it as user, even though it is a supported option, it kept complaining that I already had it installed.
Fast forward a bit, and you see me and Jamie trying everything from Regmon to Filemon to DebugView to find out what it was searching.
Finally we discovered that I previously installed NUnitAddIn (the former name of the TestDriven.Net package) on my user, and that was the problem.
Attempting to uninstall it require the msi file for this installation, yuck!
Fast forward again, get Windows Installer Cleanup Utilitity (AKA MsiZap) find out that it only work for administrators.
Then attempt to get the old msi file from Source Forge, uninstall the package, install TestDriven.Net, open Visual Stuido.Net.
Works!

{I don't know if you've noticed, but half of my posts are rants against software doing stupid things :-), this post also started this way, but I decided that I'm too negative.}

Well, I just finished a major refactoring season that would've been impossible without Tests.
I just started writing this software, but already it has several thousands of lines.
I started this project without any design, so I broke so many roles that it's lucky that I'm headed for prison tomorrow, or else I would be there today :-D.

I run FxCop on the project, and it popped several dozens of recommendations, which I know I wouldn't have been able to implement, if I didn't have the tests.
I'd a similar project, about half a year ago, I tested FxCop then, and wanted to do good, but the effort of changing & changing the project was just too much work to do.

Now, with the aid of TDD & ReSharper, the work goes very smoothly, and I'm confident that at the end, I'll have a better code, that does {roughly} the same thing.

If you aren't into TDD yet, try it. The best part isn't when you see that all the tests passed.
The best part is when you make a single inoccent change {such as moving a file from one folder to another} and you suddenly see half your tests bomb, and you just knows that this bug would've slipped to production.

I just came from such a bug, I moved a resource file to another directory, and suddenly I started seeing a lot of failed tests. After a false start {I made a change in the resource fetching code as well}, I finally found it.

P.S:
Why changing the path of a resource also change it's name in the assembly? This is stupid.

I just spent two hours trying to bring together CodeSmith & VS.Net.
The fault was not in CodeSmith's fault, but VS.Net's.
The problem is that I'm trying to get location independent project, and VS.Net model for running custom tools absolutely forbid it.

It all boils down to Vs.Net running Custom Tools with the current directory set to C:\Program Files\Microsoft Visual Stuido 2003\etc\etc\etc... and not in the current project folder, or the build directory.

What this mean is, I can't have CodeSmith's templates that reference to files in anything but absolute paths, which mean that if I change the project's path, I need to change the CodeSmith property set file.

I'm currently working on something similar to NakedObjects, a UI framework that should save you the time building UI.

Why am I building this?

• NakedObjects dotNet implementation does not work on my system, throwing java.lang.ExceptionInInitializerError (WTF?? In a .Net application?)
• I checked the Java implementation and I really like the idea, but not the implementation.
• As far as I understand the .Net port, they use the same code {one of the JVM for .Net ?} to run it, which means that I've to write ugly looking code to make it work [Ugly meaning Java-style, which is fine, but I like my C# code to adher to the .Net naming conventions.]
• The UI is horrible.
• I want to experiment a little with Reflection & UI design, both of which I've very little experiance at.
• If I'll finish it, that would be a cool thing to have.

 

Basic design is as follows:
Attributes:

• [VisibleObjectAttribute] - decorate a class/struct. Means that this an object that is visible on the UI. Several built-in objects are treated by the framework as if they'd this attribute (string, all numeric types {short, int, double, numeric, etc}, DateTime, Enum).
• [ActionAttribute] - decorate a method. Means that this is a method that is exposed to the UI.
• [ValidateParametersAttribute] - decorate a method with [ActionAttribute]. Points to a method that validate the parameters for a the decorated method. This ensure that the method would get parameters in a consistent state.

• [TitleAttribute] - decorate a string property. Used to get a nice name for an instance of an object.

• [CoreObjectAttribute] - decorate a class/struct. Inherit from VisibleObjectAttribute, means that the object is visible as the root level of the application.

• AppletCreatorAttribute - decorate a class/struct. Signify that this type supply it's own UI and should be ask to do so when presented to the user.

Classes:

• VisibleObjectContainer - contain the info regarding a type decorated with VisibleObjectAttribute {FriendlyName, Icon, Type, etc}.

• VisibleObjectInstance - contain the info about an instance of a type decorated with VisibleObjectAttribut. This is used everywhere to work with the object. This class also decide what Actions can be taken on a the object, based on its state and on the parameters.
  For instance, if you Act(“New name“) on an VisibleObjectInstance that has a method:
  [Action] string SetName(string NewName){}
  Then it will be called and the return value will be returned to you.

• Action - wraps a method decorated with [ActionAttribute], allows to query if it's valid on an object, get the nice name for it, etc.

• AppletFactory - Create the UI representation of a VisibleObjectInstance. It does so by checking a few builtin types to get the default implementation, then check if the type provide its own UI (through AppletCreatorAttribute), if not, then pass it to a default applet creator that read all the public properties/fields and gives you a form that you view/change it.I

Interfaces:

• IAppletCreator - any type that want to create its own UI need to provide an implementation of this interface.

That is all that I've right now.
Some note about terminology:
Applet is my term for a piece of the UI that may stand on its own {in the framework, represented as Control} or may be hosted in another Applet / the main form.

Some UI consideration:

• How will the UI look? I thought about dockable panels to represent the types, with the ability to drag icons to each other. But wouldn't it create a lot of clutter?
• Actions on VisibleObjectInstances will be access via right click? A menu?
• How to deal with Actions that require parameters? Pop another applet? What about complex parameters {Customer, Order, etc}.

Currently I'm working with FxCop to clean up the code, I can't maintain a naming convention in my own code, it seems.

P.S
Resharper is goodness.

I just stumbled on Desktop Sidear, and implementation of the Longhorn sidebar today.

What really impressed me, beside the polished look (I've just started learning to use this.) is that it has built-in support for multi monitors.

I do most of my work on a LCD screen set to Portrait, so I care ver much abour horizonal space, I was very please to find out that I can use it on the CRT screen when I don't care about space and clutter.

The Performance panel alone is worth using this application, I just had a major slowdown on the computer, and couldn't understand what was going on until WinRAR chimed to tell me that it finished de-compressing that 1.5 Gb archive.

It has a Disk, CPU, Mem, Swap, Network and several others.
And here I was looking at TaskMgr and seeing that everything should be fine.

Cool :-D

And free.
Go get it

Consider the following code:

using System;

using MbUnit.Core;

using MbUnit.Core.Framework;

using MbUnit.Framework;

 

namespace ConsoleApplication1

{

      [TestFixture]

      public class Class1

      {

            [STAThread]

            static void Main(string[] args)

            {

                  using(AutoRunner auto = new AutoRunner())

                  {

                        auto.Run();

                  }

 

            }

 

            [Test]

            public void TestOne()

            {

                  Assert.AreEqual(200,100+100);

            }

 

      }

}

 

What would be the result of running this code?
Well, one result is that my floppy drive lights up and Filemon register the following activity:

15:13:34.562 ConsoleApplicat:3784 IRP_MJ_CREATE  A: SUCCESS Options: Open  Access: All 
15:13:35.562 ConsoleApplicat:3784 FASTIO_DEVICE_CONTROL A: FAILURE IOCTL: 0x560000 
15:13:35.562 ConsoleApplicat:3784 IRP_MJ_DEVICE_CONTROL A: INVALID DEVICE REQUEST IOCTL: 0x560000 
15:13:35.562 ConsoleApplicat:3784 IRP_MJ_CLEANUP A: SUCCESS  
15:13:35.562 ConsoleApplicat:3784 IRP_MJ_CLOSE  A: SUCCESS  

MbUnit version 2.22.0.0;

If someone can find out what is going on here I would be more than happy.

I tried to debug it, but I can't lie my hands on a fresh pile of MbUnit code {which moved from MbUnit homepage to TestDriven.Net and for which I can find not a sign of in the TestDriven.Net site}.

Solutions are welcome.

Omer van Kloeten solved it.

 test(typeof(bool));

static void test( object t)
{
    Console.WriteLine(t.GetType().FullName);
}

Print System.RuntimeType (a subtype of System.Type) to the console.

I was expecting System.Boolean and that caused some head scratching. It was a call hidden five or six levels deep, and I couldn't for the life of me understand what was going on.