Archive for December, 2007

NUnit swallowed errorcodes

Update: The header is now in past tense as I figured out a GREAT solution; upgrade from 2.4.1 to 2.4.3!

By accident I earlier today checked in a failing unit-test to our TFS source control. While waiting for the dreaded red light from my CC tray I was about to fix it, when I suddenly discovered…

It didn’t fail the build!






Going through the build report revealed that it did in fact discover the failing test:






I couldn’t really live with that so I started investigating. I tried the following:

  • Testing the NAnt-target local on my machine – build successful
  • Manually running NUnit with all the same parameters as in the build-file, checking errorcode after run – errorcode 0 (success)
  • At least now I know it’s NUnit that is failing
  • For no good reason at all I’m just trying the failing test-assembly, leaving the other test-assemblies alone – errorcode 1 (1 failure)
  • I’m on to something
  • I add another test-assembly that doesn’t have failing tests in it – errorcode 0 (success)

It looks like NUnit forgets the result from the first test, and is just giving me the errorcode from the latest test-assembly provided!

Adding several test-assemblies to a NUnit project however does work correctly.

The solution

I didn’t want to make “static” NUnit project files, so I had to look for answers somewhere else and turned to the NUnit home pages. Earlier searches for errorcodes didn’t bring me to these pages at all, but I started looking around on the site and I found my way into the release notes.

I was using version 2.4.1 from May, and there was a 2.4.3 out from August. I downloaded it, updated my solutions tools folder, and….

It was fixed (the build failed… confused yet?!?)!

So, just to wrap it up: If you’ve been running NUnit 2.4.1 with more than one test-assembly, and your build server is happily saying the build is fine, don’t believe it!

Upgrade to a newer version and find out if your build is still fine .

No Comments

.Net Collection<T> vs. List<T>

Recently, we have gotten a couple of “fresh out of school” employees, and here the other day we went through the code of one of our applications and explained how it was built (at least how was supposed to be or “do as I tell you, don’t do as I do”).

Our O/R-mapper returns a generic Collection<T> when it is asked for a list / collection of some objects, and is consistent in doing so. The question however, was why that wasn’t a List<T>.

I had to admit I hadn’t dug into the material properly, so the question kindof got left there in open air. My bad excuse was of course I had been mostly doing managment stuff lately, and so was my companion presenter as well.

So to make a not so long story short, I had to dig into the collections that is found in .NET, and I explain them to myself for later reference, beginning with the aforementioned Collection<T> and List<T>.

The difference

Just to sum it up, Collection<T> is made for extensibility and List<T> is made for performance. See this and this from the FxCop guys.

For a full blown explanation, a great reference is also found here.

Use List<T> for all your heavy lifting internally, and expose a Collection<T> in your public API.


My first Fluent Interface experience

The starting point

A pretty standard API involves a factory and an add-method. In between the New/Create method call, we usually set some properties on the created child object. When we’re done, we add it to the collection of its parent/container. The factory and the parent/container are often collocated. Below is the standard API I had as a starting point.

IRibbonItem button = m_view.RibbonMenu.CreateButton();
button.Name = "Save";
button.Image = GetImage("save.jpg");

IRibbonPage structurePage = m_view.RibbonMenu.CreateRibbonPage();
structurePage.Name = "Standard";

IRibbonGroup bsGroup = structurePage.CreateGroup();
bsGroup.Name = "BS";

IRibbonItemGroup moveButtons = m_view.RibbonMenu.CreateButtonGroup();

IRibbonItem outButton = m_view.RibbonMenu.CreateButton();
outButton.Image = GetImage("out.jpg");
outButton.Name = "Out";

IRibbonItem inButton = m_view.RibbonMenu.CreateButton();
inButton.Image = GetImage("in.jpg");
inButton.Name = "In";


Look at the above code and then tell me you haven’t done it before. Bleh… In the above code I’m setting up a ribbon menu structure (as found in various Office 2007 products). The code is tedious to write, and there’s a lot of it. So what if I tried to wrap the API so I could set up my ribbon menu more elegantly, and how do I do that?

The result

I’m going straight to the point and I’ll show you the resulting code. (Because I’m really pleased with it and must share it!) One thing I additionally might do is to resolve the image implicitly from the name inside the configurator to make the footprint even smaller. Oh, and please don’t get hung up on the literals. I’m trying to get a concept across here, give me a break!

        Button("Save", GetImage("save.jpg"));

                Button("Out", GetImage("out.jpg")).And.
                Button("In", GetImage("in.jpg"));


Next time

Some other time I’ll talk some more about Fluent Interfaces, and the makings of my RibbonConfigurator.

No Comments