.NET（或任何其他语言或平台）中命名测试程序集的最佳约定是什么？.NET测试命名约定
什么我主要分裂之间是这些选项（请提供他人！）：
或
与第一解决方案的问题是，它看起来像.Tests是子命名空间的网站，而他们真的是多在我的脑海中平行。当新的子命名空间发挥作用时会发生什么，例如Company.Website.Controls，例如，我应该在那里放置该名称空间的测试？
也许它甚至应该是：Tests.Company.Website和Tests.Company.Website.Controls，等等。
我将与
* Company.Website - the project
* Company.Website.Tests
去简短的理由和答案很简单，测试和项目的代码有联系，因此应共享命名空间。
如果您想要在解决方案中分割代码并进行测试，您可以使用该选项。例如您可以设置与
-Code文件夹
-Tests文件夹
我个人与
Company.Tests.Website
你有一个共同的测试的命名空间和项目里面这样走了，以下相同结构的实际项目。
我实际上有一个替代的平行根。
Tests.Company.Website
它可以很好地用于非模糊的东西，当你有新的子命名空间。
为什么downvote？这位评论家能否详细说明这一点？这与任何其他建议的解决方案一样好 - 并且有一个好点。 – 2008-11-11 06:10:47
虽然这会引起引用命名空间的问题。这有点让人头疼，至于我为什么要搜索这样做的建议...（我没有投票） – ppumkin 2017-10-31 10:17:09
我通常名称测试项目项目，测试在解决方案资源管理简便起见，我用Company.Namespace.Tests的命名空间。
我构建了测试命名空间这样的大风扇：
Company.Tests.Website.xxx
Company.Tests.Website.Controls
你一样，我将这些测试看作主代码的并行名称空间结构，并为您提供了这一点。它也有，因为命名空间仍与贵公司的名称开始，你不应该有第三方库
任何命名冲突，我更喜欢去的优势：
Company.Website.Tests
我不在乎像Company.Website.Controls这样的任何子命名空间，所有的测试都进入相同的命名空间：Company.Website.Tests。您不希望测试命名空间与其他代码保持平行，因为它只会使重构命名空间花费两倍的时间。
我喜欢Company.Website.Spec，通常有每个解决方案
一个测试项目我们遵循一个嵌入的方法：
Company.Namespace.Test
Company.Namespace.Data.Test
这样的测试是接近正在测试的代码，而不必在项目之间来回切换或搜索引用，以确保有一个覆盖特定方法的测试。我们也不必维护两个独立但相同的层次结构。
我们也可以在我们增强和发展的过程中测试代码的不同部分。
起初似乎有点不可思议，但从长远来看，它对我们来说工作得非常好。
我一个解决方案过于偏爱装配的实际名称前缀“测试”因此，当我大量选择它们以拉入NUNit或您使用的任何测试工具时，可以很容易地看到所有我的单元测试程序集按字母顺序列出。
所以，如果网站是我的解决方案（和组件）的名称，我建议 -
Tests.Website.dll沿实际代码组件Website.Dll
一起去MVC开始在.net Web开发世界中成为现实，我会开始考虑这些方面。请记住，M，V和C是不同的组件，因此：
网站是您的轻量级视图。 核心包含控制器，帮助器，视图界面等.Core.Tests是您对所述Core的测试。型号适用于您的数据模型。这里最酷的是你的模型测试可以自动化你的数据库特定的测试。
这对某些人来说可能有些过头，但我发现它可以让我很容易区分问题。
这是为什么关闭？所有'基于意见'的答案仍然是一个答案，用户可以查看选项列表并选择他们认为最适合他们的选项。 – 2013-11-04 18:40:59