在 .NET（或任何其他语言或平台）中命名测试程序集的最佳约定是什么？
我主要分为这些选项（请提供其他选项！）：
或
第一个解决方案的问题在于，.Tests 看起来像是站点的子命名空间，而在我看来它们确实更平行。当一个新的子命名空间开始发挥作用时会发生什么，例如 Company.Website.Controls，例如，我应该将对该命名空间的测试放在哪里？
也许它甚至应该是：Tests.Company.Website 和 Tests.Company.Website.Controls，等等。
【问题讨论】：
标签： .net unit-testing testing naming conventions
我个人会选择
公司.测试.网站
这样你就有一个通用的测试命名空间和里面的项目，遵循与实际项目相同的结构。
【讨论】：
我实际上有一个备用并行根。
Tests.Company.Website
当您有新的子命名空间时，它可以很好地消除歧义。
【讨论】：
为了在解决方案资源管理器中简洁起见，我通常将测试项目命名为 Project-Tests，而我将 Company.Namespace.Tests 用于命名空间。
【讨论】：
我非常喜欢这样构建测试命名空间：
Company.Tests.Website.xxx
Company.Tests.Website.Controls
和您一样，我将测试视为与主代码并行的命名空间结构，这为您提供了这一点。它还有一个优点，因为命名空间仍然以您的公司名称开头，因此您不应该与 3rd 方库发生任何命名冲突
【讨论】：
我更喜欢：
Company.Website.Tests
我不关心像 Company.Website.Controls 这样的任何子命名空间，所有测试都进入同一个命名空间：Company.Website.Tests。您不希望您的测试命名空间必须与您的其余代码并行，因为它只会使重构命名空间花费两倍的时间。
【讨论】：
我更喜欢 Company.Website.Spec 并且通常每个解决方案都有一个测试项目
【讨论】：
我们采用嵌入式方法：
Company.Namespace.Test
Company.Namespace.Data.Test
通过这种方式，测试接近于被测试的代码，而无需在项目之间来回切换或寻找引用以确保有一个涵盖特定方法的测试。我们也不必维护两个独立但相同的层次结构。
我们还可以在增强和开发时测试代码的不同部分。
起初看起来有点奇怪，但从长远来看，它对我们来说效果很好。
【讨论】：
我会去的
* Company.Website - the project
* Company.Website.Tests
简短的原因和答案很简单，测试和项目在代码中链接，因此它应该共享命名空间。
如果您想在解决方案中拆分代码并进行测试，无论如何您都可以选择。例如您可以使用
设置解决方案-代码文件夹
-测试文件夹
【讨论】：
我也更喜欢在程序集的实际名称前加上“测试”，以便在我批量选择它们以拉入 NUUnit 或您正在使用的任何测试工具时，很容易看到按字母顺序列出的所有单元测试程序集。
因此，如果网站是我的解决方案（和程序集）的名称，我建议 -
Tests.Website.dll 与实际的代码组合 Website.Dll
【讨论】：
随着 MVC 开始在 .net Web 开发世界中成为现实，我会开始沿着这些思路思考。请记住，M、V 和 C 是不同的组件，所以：
网站是您的轻量级视图。 Core 包含控制器、助手、视图接口等。Core.Tests 是您对所述 Core 的测试。 模型适用于您的数据模型。很酷的一点是，您的模型测试可以自动执行特定于数据库的测试。
这对某些人来说可能有点矫枉过正，但我发现它可以让我相当轻松地分离关注点。
【讨论】：