Is it a good practice to use RowTest in a unit test.

Question

NUnit and MbUnit has a RowTest attribute that allows you to sent different set of parameters into a single test.

[RowTest]
[Row(5, 10, 15)]
[Row(3.5, 2.7, 6.2)]
[Row(-5, 6, 1)]
public void AddTest(double firstNumber, double secondNumber, double result)
{
  Assert.AreEqual(result, firstNumber + secondNumber);
}

I used to be huge fan of this feature. I used it everywhere. However, lately I'm not sure if it's a very good idea to use RowTest in Unit Tests. Here are more reasons:

A unit test must be very simple. If there's a bug, you don't want to spent a lot of time to figure out what your test tests. When you use multiple rows, each row has different sent set of parameter and tests something different.

Also I'm using TestDriven.NET, that allows me to run my unit tests from my IDE, Visual Studio. With TestDrivent.NET I cannot instruct to run a specific row, it will execute all the rows. Therefore, when I debug I have to comment out all other rows and leave only the one I'm working with.

Here's an example how would write my tests today:

[Test]
public void Add_with_positive_whole_numbers()
{
   Assert.AreEqual(5, 10 + 15);
}

[Test]
public void Add_with_one_decimal_number()
{
   Assert.AreEqual(6.2, 3.5 + 2.7);
}

[Test]
public void Add_with_negative_number()
{
   Assert.AreEqual(1, -5 + 6);
}

Saying that I still occasionally use RowTest attribute but only when I believe that it's not going to slow me down when I need to work on this later.

Do you think it's a good idea to use this feature in a Unit test?

Answer 1

Yes. It's basically executing the same test over and over again with different inputs... saving you the trouble of repeating yourself for each distinct input combination.
Thus upholding the 'once and only once' or DRY principle. So if you need to update this test you just update one test (vs multiple) tests.

Each Row should be a representative input from a distinct set - i.e. this input is different from all others w.r.t. this function's behavior. The RowTest actually was a much-asked for feature for NUnit - having originated from MBUnit... I think Schlapsi wrote it as a NUnit extension which then got promoted to std distribution status. The NUnit GUI also groups all RowTests under one node in the GUI and shows which input failed/passed.. which is cool.

The minor disadvantage of the 'need to debug' is something I personally can live with.. It's after all commenting out a number of Row attributes temporarily (First of all most of the time I can eyeball the function once I find ScenarioX failed and solve it without needing a step-through) or conversely just copy the test out and pass it fixed (problematic) inputs temporarily