C# 在单元测试中使用RowTest是一种好的实践吗

NUnit和MbUnit具有RowTest属性，允许您将不同的参数集发送到单个测试中

[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);
}

我曾经是这个功能的超级粉丝。我到处都用。然而，最近我不确定在单元测试中使用RowTest是否是一个好主意。以下是更多的原因：

单元测试必须非常简单。如果有bug，你不想花很多时间去弄清楚你的测试测试是什么。当您使用多行时，每行都有不同的参数集，并测试不同的内容

我还使用了，它允许我从IDE Visual Studio运行单元测试。对于TestDrivent.NET，我无法指示运行特定行，它将执行所有行。因此，当我调试时，我必须注释掉所有其他行，只留下我正在处理的那一行

下面是一个如何编写我今天的测试的示例：

[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);
}

说我仍然偶尔使用RowTest属性，但只有当我相信它不会让我在以后需要处理这个问题时放慢速度时

---

您认为在单元测试中使用此功能是一个好主意吗？

是。它基本上是用不同的输入反复执行相同的测试。。。省去了为每个不同输入组合重复输入的麻烦。
因此，坚持“一次仅一次”或干燥原则。因此，如果需要更新此测试，只需更新一个测试（与多个测试相比）

每一行都应该是来自不同集合的代表性输入，即该输入不同于所有其他w.r.t.此函数的行为。 RowTest实际上是NUnit的一个备受追捧的功能，它起源于MBUnit。。。我认为Schlapsi把它写成了NUnit的一个扩展，然后被提升为std的分发状态。NUnit GUI还将所有行测试分组到GUI中的一个节点下，并显示哪些输入失败/通过。。这很酷

---

“需要调试”的一个小缺点是我个人可以接受的。。毕竟，它是暂时注释掉一些行属性（首先，大多数情况下，当我发现ScenarioX失败时，我可以直接查看函数并解决它，而不需要逐步解决），或者相反，只是复制测试并暂时通过固定（有问题的）输入。

我也提到过。。这和我天生的懒惰很相配。