Dave Donaldson

Some TDD Pragmatism

Saturday, June 24 2006

Karl Seguin over at CodeBetter recently started blogging about his entry into the TDD world. He's just getting started with the test-first approach and I think it's cool that he's blogging about his learning process along the way. Today he wrote a post where he showed a couple tests, one for testing the creation of an instance of a class and another for testing a property value on that class.

I think Karl took the right approach with these tests, afterall he needed to start somewhere, but I think he'll find over time that writing certain tests aren't too meaningful because you can make certain assumptions about the runtime you're using. For instance, below is his property test:

[Test]
public void CanSetIndicatorName()
{
 Indicator indicator = new Indicator();
 Assert.IsNull(indicator.Name);
 indicator.Name = "Test Indicator";
 Assert.AreEqual("Test Indicator", indicator.Name);
}

Looking at this test there are two asserts: one to check if the instance of the Indicator class is null and one to check if the Name property is equal to the value he just set it to. To me, these checks tend to be extra baggage I don't need to worry about. Think about it. If the .NET runtime can't create a new instance of your class and/or can't set the value of a property, you've got much larger issues to worry about than getting these tests to pass. Do you really need to write a test for every property on every class in your entity model just to check if those properties can be set? I don't think that is where the value of TDD comes into play. That's just going a bit too extreme for me.

That being said, there are obviously times where a test like this is valuable, such as when you execute a business rule where the output is a change to a known property. You should then assert that property to make sure you got (or didn't get) the expected value. But creating an instance of a class just to set a property value and then do the assert is just overkill and not really time well spent. And I know some people who have been practicing TDD for awhile that still do this just so they can gain a couple extra percentage points for their code coverage metrics. But that's a whole other issue.

This post isn't a knock on Karl by any means. I applaud him for putting is TDD trials and tribulations out in public for all to see. A lot of people would never do that. In fact, I was just going to leave a comment on his post except it got too big and I figured I would just post here so that he would see the trackback.

Jeffrey Palermo said it best in his comment on Karl's post: "I'm using common sense as my guide more and more."