The following is a screenshot from a recent LinkedIn architecture slide deck:

7,000+ unit tests.

There’s a principle (little-”p”) in the Agile / XP world that your unit tests should roughly reflect your software requirements.   Part of this has to do with the fact that if there’s a requirement, it should be tested, and part of it has to do with the low-documentation/code-sharing ethic.  In this second scenario, a new developer should be able to get a pretty good handle on what the tested code is supposed to do merely by going through the unit tests.

Of course, as with most software rules of thumb, that’s an abstraction, but it speaks to a real mindset.

I’ve found during those times where I get “stuck” playing around with a new piece of software I’m developing, that when I go back and look at the unit tests, it’s a lot of property testing, and not nearly enough method testing.  In other words, I overemphasize state at the expense of behavior.  This is a bad thing.  In the first case, properties are too easy to test: get/set blocks, assignments and .AreEqual calls, etc.  Methods are harder to test — branches, function overloading, loops, messy stuff.  In the second case, software is meant to DO something — even state changes are an active process, in the sense that something acts on the software to change its state.

Part of my problem may be too heavy an OOP mindset, in the sense that my first instincts are to say “what is this thing?” rather than “how does this thing behave?”

The answer?  Back to theory to get a fresh perspective.  Nothing like snuggling up with Grady Booch to get back to first principles and recharge the batteries.

I have a VS 2005 solution that I just converted over to VS 2008 using the built-in Conversion Wizard.  This starts automatically when you open the VS 2005 solution in the 2008 IDE.  I run as a local Administrator and so I didn’t have any problems with the conversion.

However, a couple unit tests are failing.  One is a simple sort test to make sure that in-place sorting returns the same results when you sort on a field that has the same value across both collection items.  For example, sorting the input collection

{ “A”, “foo” }

{ “B”, “foo” }

by the second column should return the same list in the same order.  What is actually happening is that the list is reversed.  All of my CompareTo() calls in the body of my custom Sort() class return zero when I step through the code, but for some reason the framework is seeing fit to swap my items anyway.

This test worked in VS 2005 / .NET 2.0.

I am starting to implement some unit tests for my custom DataSourceControl / DataSourceView classes and immediately ran into the problem of not having a valid HttpContext against with to instantiate my objects.

Googling, I found the following helpful links:

http://weblogs.asp.net/jeff/archive/2004/05/31/145111.aspx

http://haacked.com/archive/2005/06/11/simulating_httpcontext.aspx

http://thewebfarm.com/blog/archive/2006/04/28/402.aspx

I was also digging through some old source code and found this link as a reference, but it appears dead:

http://righteousindignation.gotdns.org/blog/archive/2004/04/13/149.aspx