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.

[RowTest]
[Row(0,1,true)]
[Row(1,1,true)]
[Row(1,0,false)]
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));
}
 
[Test]
public void RangeValidator_accepts_lower_less_than_upper()
{ RangeValidatorTestHelper(0, 1, true); }


[Test]
public void RangeValidator_accepts_lower_equals_upper()
{ RangeValidatorTestHelper(1, 1, true); }
 
[Test]
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.