Who needs RowTest?

I’ve heard a lot of developers bash one unit testing framework or another because of the lack of the RowTest attribute, which I beleive originated in MbUnit, at least as far as .net developers are concerned. If it came over from the Java world, well… that’s outside of my current scope and I don’t care. What bothers me is that some developers will use the presence or absence of the RowTest attribute as criteria for accepting or rejecting an entire testing framework, when in my opinion the attribute is totally unnecessary in the first place. You can achieve the same (or better) results using code that will work in ANY unit testing framework (barring the usual attribute naming differences, of course).

Let me start by saying that if you want to run TestA with three different sets of input, I presume it’s because those three sets of input are each supposed to provoke a slightly different response form the test, otherwise why bother? Perhaps you are explicitly testing the edge cases to make sure that everything works as expected on either side of a boundary without blowing up. Let’s assume that we want to test some method that takes a lower and an upper bound, and lets you know whether they are valid.  We write a test that looks something like the following, which takes a lower and upper bound, and a Boolean indicating whether the test should succeed or fail.

public void RangeValidatorTest(int lower, int upper, bool expected)
var target = new RangeValidator();

Assert.AreEqual(expected, target.Validate(lower, upper));


The problem here is that nothing about the input data tells me why it’s special. What is different about row 1 as opposed to row 2? It’s a contrived example, sure, but stay with me. Now do the same thing without the RowTest attribute. I hear people complaining already: “But I don’t wanna write the same test three times”. <arnold>Stop whining!</arnold>

I’m not talking about wholesale copy and paste here. you just factor the guts into a non-test method.  It’s easy, you’ll see.

public void RangeValidatorTestHelper(int lower, int upper, bool expected)
    var target = new RangeValidator();
    Assert.AreEqual(expected, target.Validate(lower, upper));


public void RangeValidator_accepts_lower_less_than_upper()
{ RangeValidatorTestHelper(0, 1, true); }

public void RangeValidator_accepts_lower_equals_upper()
{ RangeValidatorTestHelper(1, 1, true); }


public void RangeValidator_rejects_lower_greater_than_upper()
{ RangeValidatorTestHelper(1, 0, false); }

It’s a little wordier, sure, but I like wordiness, personally. Notice how the actual tests each have their own intelligent names now. I can read the test results without having to “parse in” the parameters to figure out what’s going wrong with a test now.

But hey, that’s just me.

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Who needs RowTest?

  1. Noam says:

    NUnit has an option for adding a description to each TestCase (=Row). What would be the difference between that and writing seperate test methods with discriptive names?

  2. Mel says:

    The effect would be the same, I suppose. One advantage to the hand-written approach above would be setting a breakpoint on just one of the cases, though. The main point of the article is that rejecting a framework because it doesn\’t have the RowTest attribute is fallacious. RowTest is just syntactic sugar for functionality that you can still implement in any of the available frameworks. Teams should choose a framework based on more tangible criteria such as integration with other tools they are using. For instance, before the latest ReSharper, you could justify NUnit over MSTest based on a preference for R#\’s test runner. If you are running a project using TFS, you may want to use MSTest because of its better integration. I hear that VS2010 is going to support NUnit test integration, though, so that may not be an issue much longer. If TFS/VS2010 fully support NUnit, then people may flock back to that simply because they prefer to support an open source framework where possible.Basically, there are plenty of valid reasons to choose one framework over another… I just don\’t think that RowTest is one of them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s