每个单元测试有多种安排/断言？

Question

我们一群人（.NET 开发人员）正在谈论单元测试。不是任何一种框架（我们已经提到了 MSpec、NUint、MSTest、RhinoMocks、TypeMock 等）——我们只是泛泛而谈。

我们看到许多语法强制每个场景进行不同的单元测试，但我们没有看到一种方法可以将一个单元测试与各种输入或场景重复使用。此外，我们看不到在给定测试中实现多个断言的途径，而不会导致早期断言的失败威胁到后续断言的测试（在同一测试中）。

如今 .NET 单元测试（基于状态或行为）中是否发生了类似的情况？

Answer 1

查看 NUnit 中的 [TestCase(params)]
允许使用不同的输入进行相同的测试。

另外，对于多重断言的事情，
看一下 OAPT（每个测试一个断言）运行程序 - 它承诺使用多个断言进行测试并将每个断言作为自己的测试运行：
http://rauchy.net/oapt/

Answer 2

我们没有看到一种方法可以将一个单元测试与各种输入或场景重复使用。

“标准”设置/拆卸方法已经有助于重用测试代码。最重要的是，我相信许多 .Net 单元测试框架都实现了与 Java 对应的 JUnit 和 TestNG 相同或相似的功能，它们支持参数化测试等。

此外，我们看不到在给定测试中实现多个断言的途径，而早期断言的失败不会威胁到后续断言的测试（在同一测试中）。

在我的解释中，测试方法测试单个用例。如果断言失败，则测试失败，并且有充分的理由尽快修复它。单元测试的正常状态应该是 100% 成功，在这种情况下，所有测试中的所有断言都通过。换句话说，失败的测试应该是例外而不是常态；而且我不太担心特殊情况。如果您仍然担心，您可以随时安排您的测试方法，使每个测试方法仅包含一个断言。

Answer 3

我们看到许多语法强制每个场景进行不同的单元测试，但我们没有看到一种方法可以将一个单元测试与各种输入或场景重复使用。

使用 MBUnit 中的 RowTest 或 xUnit.net 中的 Theories 来改变输入变量是很常见的。谷歌其中之一，你会发现几个例子。 Ben Hall 有一篇关于在 xUnit.net 中使用理论的精彩文章： http://blog.benhall.me.uk/2008/01/introduction-to-xunitnet-extensions.html

此外，我们没有看到在给定测试中进行多个断言的途径，而早期断言的失败不会威胁到后续断言的测试

在单个测试中使用多个断言是很好的（而且很常见）。这里需要遵循的概念是单个单元测试应该测试特定行为或单个代码单元。如果一个单元测试中有 3 个断言，并且第一个断言失败，则此时其他 2 个断言是否通过并不重要（并且大多数测试运行者在一个测试失败后不会在单个测试中运行其余断言） ，重要的是一个失败的断言。

关于每次测试是否应该测试多个行为/代码单元，有很多意见。出于多种原因，我更喜欢每次测试一种行为。最重要的是，当其中一项测试失败时，我或其他人将不得不返回并阅读测试，以准确了解失败的原因和原因。如果我们必须通读一个不仅仅测试单个行为的单元测试，那么我们就是在浪费时间。在较小的块中进行测试时，确保为代码编写正确的测试也更容易。我强烈建议您阅读 Roy Osherove 的《单元测试的艺术》单元测试的艺术。

Answer 4

您可以采取的一种解决方案是将场景放入 SetUp 函数中。

在 NUnit 中，您可以使用如下方法：

private class1 c1;

[SetUp()]
private void Setup()
{
c1 = new class1{Prop1 = 'A', Prop2= 'B'};
}

然后进行两个测试：

[Test()]
private void Property1_Is_A
{
   Assert.AreEqual('A', c1.Prop1);
}

[Test()]
private void Property2_Is_B
{
   Assert.AreEqual('B', c1.Prop2);
}

每次执行测试之前都会调用 SetUp。我想您可以使用构造函数执行类似的操作，该构造函数将被调用一次。

也就是说，有一些很好的论据反对这一点，因为单独的测试应该设置它需要的一切。但这些并不是硬性规定。