您是否将单元测试放在同一个项目或其他项目中？

为方便起见,您是否将单元测试放在同一个项目中,或者将它们放在单独的组件中？

如果你像我们一样将它们放在一个单独的程序集中,我们最终会在解决方案中添加一些额外的项目.这对于编码时的单元测试很有用,但是如果没有所有这些额外的组件,你如何发布应用程序呢？

单独的项目,但在同一解决方案.(我为产品提供了独立的测试和生产代码解决方案 - 这太可怕了.你总是在两者之间切换.)

单独项目的原因如其他人所述.请注意,如果您使用的是数据驱动的测试,那么如果将测试包含在生产装配中,则可能会导致相当大的膨胀.

如果需要访问生产代码的内部成员,请使用InternalsVisibleTo.

在我看来,单元测试应该放在与生产代码不同的组件中.以下是将生产代码放在同一装配或组件中的单元测试的一些缺点:

单元测试随附生产代码.产品代码附带的唯一内容是生产代码.

单元测试会使组件不必要地膨胀.

单元测试可以影响构建过程,如自动或连续构建.

我真的不知道任何专业人士.有一个额外的项目(或10)不是一个骗局.

编辑:有关构建和运输的更多信息

我还建议任何自动构建过程将生产和单元测试放到不同的位置.理想情况下,单元测试构建过程仅在生成代码构建时运行,并将产品文件复制到单元测试目录中.这样做会导致实际的位被分开以便运输等.此外,在特定目录中的所有测试上运行自动单元测试是相当简单的.

总而言之,以下是每日构建和测试以及位和其他文件传输的一般概念:

生产构建运行,将生产文件放入特定的"生产"目录.

仅建立生产项目.

将编译的位和其他文件复制到"生产"目录中.

将位和其他文件复制到发布候选目录中,即圣诞节发布目录将是"Release20081225".

如果生成构建成功,则运行单元测试构建.

将生产代码复制到"tests"目录.

构建单元测试以"测试"目录.

运行单元测试.

将构建通知和单元测试结果发送给开发人员.

当一个候选版本(如Release20081225)被接受时,发送这些位.

我不理解经常反对使用生产代码部署测试.我领导了一个小团队(从14人增加到130人).我们有六个左右的Java应用程序,我们发现它非常有价值,可以将测试部署到字段中以便在特定的机器表现出异常的行为.在现场发生随机问题,能够以零成本投入几千个单元测试是非常宝贵的,并且经常在几分钟内诊断出问题......包括安装问题,片状RAM问题,机器特定问题,网络问题,我认为将测试带入现场是非常有价值的.此外,随机时间会出现随机问题,让位于那里的单元测试等待立即执行是很好的.硬盘空间很便宜.就像我们试图将数据和功能保持在一起一样(OO设计),我认为在将代码和测试保持在一起(功能+测试验证功能)方面有一些根本性的价值.

我想在C#/ .NET/Visual Studio 2008中将我的测试放在同一个项目中,但我仍然没有调查过这个实现它的想法.

将Foo.cs保存在与FooTest.cs相同的项目中的一大好处是,当一个类缺少兄弟测试时,开发人员会不断被提醒!这鼓励了更好的测试驱动编码实践......漏洞更加明显.

将Unit测试放在与代码相同的项目中,以实现更好的封装.

您可以轻松地测试内部方法,这意味着您不会将方法设为公共内部方法.

让单元测试接近您正在编写的代码也是非常好的.编写方法时,您可以轻松找到相应的单元测试,因为它位于同一个项目中.当你构建一个包含unitTests的程序集时,unitTest中的任何错误都会给你一个compilereerror,所以你必须保持你的unittest是最新的,只是为了构建.在单独的项目中进行单元测试可能会导致一些开发人员忘记构建单元测试项目,并在一段时间内错过了破坏的测试.

您可以使用编译标签(I​​F #Debug)从生产代码中删除单元测试.

自动集成测试(由NUnit制作)应该在一个单独的项目中,因为它们不属于任何单个项目.

我的单元测试总是在一个单独的项目中进行.事实上,对于我在我的解决方案中的每个项目,都有一个独立的测试项目.测试代码不是应用程序代码,不应与其混合.将它们保存在单独的项目中的一个优点 - 至少使用TestDriven.Net - 是我可以右键单击测试项目并运行该项目中的所有测试,只需单击一下即可测试整个应用程序代码库.

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);
     }
}