你把unit testing放在同一个项目还是另一个项目？

你为了方便把unit testing放在同一个项目中，还是把它们放在一个单独的程序集中？

如果像我们这样将它们放在一个单独的程序集中，那么解决scheme中会包含一些额外的项目。 在编写代码的unit testing中很棒，但是如何在没有所有这些额外程序集的情况下释放应用程序呢？

Answer 1

在我看来，unit testing应该放在与生产代码不同的程序集中。 以下是将unit testing放置在同一个程序集或程序集中的一些缺点，因为生产代码是：

1. unit testing随产品代码一起发货。 产品代码附带的唯一东西是生产代码。
2. 通过unit testing，组件将会不必要的膨胀。
3. unit testing可以影响构build过程，如自动或连续构build。

我真的不知道任何优点。 有一个额外的项目（或10）不是一个骗局。

编辑：关于构build和运输的更多信息

我会进一步build议任何自动构build过程将生产和unit testing放到不同的位置。 理想情况下，unit testing构build过程仅在生成代码构build时运行，并将产品文件复制到unit testing目录中。 这样做会导致实际的位被分离出来等等。另外，在特定目录的所有testing中的这一点上运行自动unit testing是相当简单的。

总而言之，下面是每天构build和testing以及传输位和其他文件的总体思路：

1. 生产构build运行，将生产文件放入特定的“生产”目录。
   1. 只build立生产项目。
   2. 将编译的位和其他文件复制到“生产”目录中。
   3. 将位和其他文件复制到候选版本目录中，也就是圣诞节版本目录将是“Release20081225”。
2. 如果生产build立成功，则unit testing生成运行。
   1. 将生产代码复制到“testing”目录。
   2. build立unit testing以“testing”目录。
   3. 运行unit testing。
3. 将构build通知和unit testing结果发送给开发人员。
4. 当发布候选版本（如Release20081225）被接受时，发送这些位。

Answer 2

单独的项目，但在相同的解决scheme。 （我从事的是testing和生产代码的单独解决scheme的产品 – 这太可怕了，你总是在两者之间切换。）

其他项目的原因正如其他人所说的那样。 请注意，如果您使用的是数据驱动的testing，那么如果将testing包括在生产部件中，则可能会导致相当大的膨胀。

如果您需要访问生产代码的内部成员，请使用InternalsVisibleTo 。

Answer 3

我不明白经常反对部署生产代码testing。 我带领一支小型微型车队（从14人增加到130人）。 我们有六个左右的Java应用程序，我们发现它非常有价值，可以将testing部署到现场，在特定的机器上执行这些testing，以显示不寻常的行为。 在现场发生的随机问题，能够以零成本投入几千个unit testing是无价的，并且经常在几分钟内诊断出问题…包括安装问题，片状RAM问题，机器特定问题，片状networking问题，等等等等。我认为把testing投入到这个领域是非常有价值的。 另外，随机的问题随机出现，unit testing坐在那里已经等待执行了。 硬盘空间很便宜。 就像我们试图将数据和function保持在一起（OOdevise）一样，我认为将代码和testing放在一起（函数+validation函数的testing）是非常有价值的。

我想把我的testing放在C＃/ .NET / Visual Studio 2008中的同一个项目中，但是我还没有研究这个来达到目的。

将Foo.cs保存在与FooTest.cs相同的项目中的一个很大的好处是，当一个类缺less兄弟testing时，开发者会不断提醒！ 这鼓励更好的testing驱动编码实践…漏洞更明显。

Answer 4

我的unit testing总是在一个单独的项目中进行。 事实上，对于我的解决scheme中的每个项目，都有一个独立的testing项目。 testing代码不是应用程序代码，不应与其混淆。 将它们保存在单独的项目中的一个好处是至less使用TestDriven.Net，我可以右键单击某个testing项目，然后运行该项目中的所有testing，只需单击一下即可testing整个应用程序代码库。

Answer 5

将unit testing放在与代码相同的项目中以实现更好的封装。

你可以很容易地testing内部方法，这意味着你不会公开本应该是内部的方法。

unit testing接近您正在编写的代码也是非常好的。 当你编写一个方法时，你可以很容易地find相应的unit testing，因为它在同一个项目中。 当你构build一个包含unitTests的程序集时，unitTest中的任何错误都会给你一个compilereerror，所以你必须保持你的unittest是最新的，只是为了构build。 在一个单独的项目中进行unit testing，可能会导致一些开发人员忘记构buildunit testing项目，并在一段时间内忽略了破坏性testing。

你也可以使用编译标签（I​​F＃Debug）从产品代码中删除unit testing。

自动集成testing（由i NUnit生成）应该在一个独立的项目中，因为它们不属于任何单个项目。

Answer 6

如果使用NUnit框架，还有一个额外的原因是将testing放在同一个项目中。 考虑下面的生产代码与unit testing混合的例子：

 public static class Ext { [TestCase(1.1, Result = 1)] [TestCase(0.9, Result = 1)] public static int ToRoundedInt(this double d) { return (int) Math.Round(d); } } 

这里的unit testing作为正在testing的代码的文档和规范。 我不知道如何实现自我logging的效果，testing位于一个单独的项目中。 函数的用户将不得不searchtesting来查看那些不太可能的testing用例。

更新 ：我知道TestCase属性的这种用法并不是NUnit的开发人员所满足的，但为什么呢？

Answer 7

我把它们放在单独的项目中。 程序集的名称反映了命名空间的名称，作为我们的一般规则。 所以如果有一个叫做Company.Product.Feature.sln的项目，它有一个输出（程序集名称）的Company.Product.Feature.dll。 testing项目是Company.Product.Feature.Tests.sln，产生Company.Product.Feature.Tests.dll。

您最好将它们保存在一个解决scheme中，并通过configurationpipe理器控制输出。 我们为每个主要分支（开发，集成，生产）提供一个命名configuration，以代替使用默认的debugging和发布。 configuration完成后，您可以通过单击configurationpipe理器中的“生成”checkbox来包含或排除它们。 （要获取configurationpipe理器，请右键单击该解决scheme并转到configurationpipe理器。）请注意，我发现Visual Studio中的CM有时会出错。 有几次，我不得不进入项目和/或解决scheme文件来清理它创build的目标。

另外，如果你正在使用Team Build（并且我相信其他.NET构build工具是相同的），那么你可以把这个构build与一个命名configuration关联起来。 这意味着如果你没有为你的“生产”构build构build你的unit testing，例如，构build项目也可以知道这个设置，而不是因为它们被标记为这样。

另外，我们用XCopy从构build机器中删除。 该脚本将只是省略复制任何名称* .Tests.Dll被部署。 这很简单，但工作。

Answer 8

我在同一个项目和不同的项目之间波动。

如果你发布一个库，发布testing代码和产品代码是一个问题，否则我发现它通常不是（尽pipe在你尝试之前有一个强大的心理障碍）。

在同一个项目中进行testing时，我发现在testing和testing代码之间切换更容易，而且更容易重构/移动它们。

Answer 9

我会说保持他们分开。

除了提到的其他原因之外，一起进行代码和testing会扭曲testing覆盖率数字。 当您报告unit testing覆盖率时，报告的覆盖率更高，因为在运行unit testing时覆盖了testing。 在报告集成testing覆盖率时，报告的覆盖率较低，因为集成testing不会运行unit testing。

Answer 10

罗伯特·洛佩兹（Robert Lopez）的Flood NN库的unit testing框架让我深受启发。 它为每个unit testing的类使用不同的项目，并且拥有一个包含所有这些项目的解决scheme，以及编译和运行所有testing的主项目。

整洁的事情也是项目的布局。 源文件在一个文件夹中，但是VS项目的文件夹在下面。 这使您可以为不同的编译器创build不同的子文件夹。 所有的VS项目都附带代码，所以任何人都可以很容易地运行任何或所有的unit testing。

Answer 11

单独的项目，虽然我自己辩论是否应该分享同样的svn。 目前，我给他们单独的svn仓库，一个叫

“MyProject” – 用于项目本身

和一个叫

“MyProjectTests” – 与MyProject关联的testing。

这是相当干净的，有承诺的项目和承诺的testing是相当独立的优势。 这也意味着如果需要的话你可以交出项目的svn，而不必发布你的testing。 这也意味着你可以有你的testing和项目的分支/干线/标签目录。

但是我越来越倾向于在每个项目的单个svn仓库中拥有类似以下内容的东西。

我的项目
 | \干线
 |  | \代码
 |  \testing
 | \标签
 |  | \ 0.1
 |  |  | \代码
 |  |  \testing
 |  \ 0.2
 |  | \代码
 |  \testing
 \分行
   \ MyFork
    | \代码
     \testing

我很想知道其他人对此解决scheme的看法。