最佳实践：组织单元测试

Question

我有一个包含超过270个项目的解决方案，其中包括各种文件夹等。想象一下，每个项目都有单元测试，你认为最好的组织方式是什么？每个项目应该将单元测试放在附近，还是我应该为它们创建特别的文件夹，甚至只为单元测试创建不同的解决方案。

对于这样规模庞大的解决方案/项目，您如何组织它们？

- Lukas Šalkauskas

Answer 1

一份包含270个项目的单一解决方案听起来就像是一个问题。打开VS需要多长时间？ :) （说真的，您可以将一些项目合并在一起或拆分解决方案吗？）

通常，我会将单元测试放在它们自己的项目中，但在同一个解决方案中。在项目中，镜像生产项目的文件夹/命名空间结构。看看Noda Time如何组织作为一个例子。我曾经在一些公司工作过，他们把单元测试保留在另一个解决方案中，但那真的很痛苦。（他们有一个还算不错的理由：测试使用的是VS2005版本，而生产代码则是2003版本。）

有时，我会将测试项目的默认命名空间设置为与生产项目相同-在Java中比.NET更重要（因为它让您可以获取软件包访问成员），但它仍然很有帮助，因为这意味着您要测试的类不需要被导入。

- Jon Skeet

---

我不喜欢将它们放在一个独立的项目中，因为这会使得测试内部类和方法更加困难。 - tster

@Arnis：为什么？我从来没有发现一个测试项目对于一个生产项目有任何问题。你遇到了什么问题？ - Jon Skeet

@tster: 这就是 InternalsVisibleToAttribute 的作用。请参见 http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx - 如果你在生产项目中测试代码，则最终会从你的生产程序集中引用测试框架等内容，同时还要将所有测试代码（以及潜在的大量测试数据）放入程序集中。非常糟糕。 - Jon Skeet

@Jon，我特别喜欢这个网站！！！我每天都学到新东西。太棒了！ - tster

@tster：单元测试的一个非常重要的规则是：只测试公共API（受保护的算作公共）。测试内部会阻碍重构，而且在任何情况下，你都应该能够通过公共API访问到所有的代码。 - Mark Seemann

Answer 2

每个目标项目应该有一个(或多个)单元测试项目。这是您保持灵活性并将每个单元测试套件与目标项目一起变化的唯一方式。

如果您只有一个覆盖多个目标项目的单元测试项目，则会在这两个项目之间创建人为的紧密耦合，因为您将无法编译单元测试项目而不涉及所有目标项目。这再次使得难以独立测试单个项目 - 这就是单位测试的全部内容。

如果需要在多个测试目标之间共享测试代码，您可以始终创建一个带有通用可重用测试API的共享库，只要它不引用任何目标项目即可。

话虽如此，我必须同意Jon Skeet的观点，认为拥有270个项目的解决方案是一种结构上的问题，必须首先加以解决(除非它是用于自动化构建的“全部构建”解决方案)。

- Mark Seemann

Answer 3

从内置的Visual Studio测试框架切换到Gallio后，我开始将我的测试放在同一项目中的Test文件夹中。对于小助手类，我甚至可以在同一文件夹中定义一个单元测试。只要你的命名空间相对较小（我不喜欢有大量的命名空间文件夹），这对我来说并不会增加太多杂乱的东西。无论如何，当这些类存在一段时间并且稳定后，您可以将这些单元测试移动到单独的文件夹中。

- tster

---

所以当您发布生产二进制文件时，它们是否仍包含测试类？您是否也会发布测试框架程序集，这些程序集很可能是您的项目所引用的？测试数据呢？ - Jon Skeet

我从来没有太多考虑过这个问题，因为我主要开发内部应用。但是，是的，我想测试代码也会被发布。将来我需要考虑这个问题。 - tster