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中有一篇关于使用Theory的好文章：http://blog.benhall.me.uk/2008/01/introduction-to-xunitnet-extensions.html

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

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

关于每个测试是否应该测试多个行为/单位代码，有很多意见。出于多种原因，我更喜欢每次测试一种行为。最重要的一点是，当其中一个测试失败时，我或其他人将不得不回去阅读测试以确切了解失败的原因和原因。如果我们必须通读单元测试，而不仅仅是测试单个行为，那么我们就是在浪费时间。在较小的块中进行测试时，确保为代码编写正确的测试也要容易得多。我强烈建议您获取Roy Osherove的T he Art of Unit Testing副本。

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。我想你可以做一些与被调用一次的构造函数类似的东西。

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

每单元测试多次安排/断言？

4 个答案: