有一个专门用于单元测试的单独项目有什么优点和缺点？

Question

您能否比较将所有单元测试放在一个专门用于单元测试的项目中与将单元测试驻留在相关程序集中的优缺点？

谢谢

Answer 1

对于我自己来说，有两个直接的优点。

首先，当我发送这些位时，我仅发送用于相关应用程序的代码。

另一个好处是在持续集成 (CI) 环境中，我可以将单元测试框架指向与预定义名称模式匹配的程序集列表，例如以“Test”结尾的任何程序集。

Answer 2

主要优点是关注点分离。它们的类和测试是完全正交的，应该分开。其他优点和缺点确实可以从中衍生出来，例如用户需要应用程序，但您必须交付应用程序+测试，因为它们会被尖峰化。

Answer 3

将单元测试直接包含在正在测试的代码旁边时的主要缺点是需要额外的机制来从交付的二进制文件中排除测试代码。

在单独的项目中隔离单元测试时，我能想到的唯一问题是，根据您使用的语言，测试纯内部类可能会变得困难。对于当前的 C++ 项目，我使用具有特定“单元测试”构建配置的单独项目，其中我的产品构建为静态库而不是 dll，从而允许测试项目访问任何类型或函数，无论其类型或函数如何出口规格。

Answer 4

特定于 C#：

请注意，类及其测试是紧密耦合的。分成两个装配体可以跨装配体边界延伸耦合链接。

我更喜欢将单元测试放在与他们正在测试的类相同的程序集中。对于命名空间 N 中的每个类 C，我会将单元测试放在命名空间 N.Tests 的类 CTests 中。

测试非公共类很简单。 （TDD 中常见的说法是，您不应该对私有成员进行单元测试；我同意。这里我谈论的是 internal 类和 internal 成员。）

我不知道不必处理那么多的程序集。

我应该补充一点，我不介意将我的单元测试发送给我的用户。如果它们通过拨号下载或在存储空间最小的系统上运行，情况会有所不同。

旁白：

如果可以的话，我会将单元测试放在嵌套类中，如下所示：

public class C
{
    // note 'private' accessibility. 
    [TestFixture]
    class Tests
    {
        // tests here
    }

    // Implementation of C here
}

一些优点：

• 重命名 C 不需要重命名 CTests。

• 我确切地知道在哪里可以找到我的测试。

• 测试和被测代码总是在一起。

这仅适用于班级规模较小的情况。一旦它们变大，文件就会变得巨大。可以使用 partial 类将它们放在单独的文件中。

不幸的是，NUnit 和 Visual Studio 的单元测试框架看不到非公共测试装置。我不认为排除非公开测试有什么好处，但这就是它们的工作原理。

Answer 5

将它们保留在单独的程序集中的优点：

• 不会不必要地增加正在测试的模块的复杂性，并且不会违反关注点分离。

• 您不需要在整个解决方案中引用您的测试框架。

• 它将使您能够（或至少使您更容易）在 CI 环境中设置您的项目。