.NET Testing Naming Conventions在.NET(或任何其他语言或平台)中命名测试程序集的最佳约定是什么？ 我主要划分的是这些选项(请提供其他选项！)：
要么
第一个解决方案的问题在于，看起来.Tests是该站点的子命名空间，而在我看来，它们确实更加相似。 当一个新的子命名空间(例如Company.Website.Controls)开始发挥作用时，会发生什么情况？例如，我应该将该命名空间的测试放在哪里？ 甚至应该是：Tests.Company.Website和Tests.Company.Website.Controls，依此类推。 我会去
简短的原因和答案很简单，测试和项目通过代码链接在一起，因此应该共享名称空间。 如果您想拆分代码并在解决方案中进行测试，则仍然可以选择该选项。例如您可以使用以下方法设置解决方案 -代码文件夹
-测试文件夹
我个人会去 公司。测试网站 这样，您将拥有一个通用的测试名称空间和其中的项目，并遵循与实际项目相同的结构。 我实际上有一个备用并行根。 Tests.Company.Web站点 当您拥有新的子命名空间时，它可以很好地消除歧义。 我非常喜欢这样构造测试名称空间： Company.Tests.Website.xxx Company.Tests.Website.Controls 像您一样，我将测试视为与主代码的并行名称空间结构，这为您提供了这一点。这样做还有一个好处，因为命名空间仍然以您的公司名称开头，因此您与第三方库之间的命名冲突不会出现 我也更喜欢以" Tests"作为程序集实际名称的前缀，这样当我批量选择它们放入NUNit或使用的任何测试工具中时，可以轻松地按字母顺序列出所有我的单元测试程序集。 因此，如果网站是我的解决方案(和程序集)的名称，我建议- Tests.Website.dll与实际的代码汇编Website.Dll一起使用 我们遵循嵌入式方法：
这样，测试就可以与正在测试的代码接近，而不必在项目之间来回切换或寻找引用以确保存在涵盖特定方法的测试。我们也不必维护两个单独的但完全相同的层次结构。 当我们增强和开发时，我们还可以测试代码的不同部分。 乍一看似乎有些不可思议，但从长期来看，它对我们来说确实运作良好。 随着MVC开始在.net Web开发世界中成为现实，我将开始沿着这些思路进行思考。请记住，M，V和C是不同的组件，因此：
网站是您的轻量级视图。 对于某些人来说，这可能是过大的杀伤力，但我发现它使我可以很容易地将关注点分开。 我更喜欢Company.Website.Spec，每个解决方案通常有一个测试项目 我更喜欢： 公司网站测试 我不在乎像Company.Website.Controls这样的子命名空间，所有测试都进入同一个命名空间：Company.Website.Tests。您不希望您的测试名称空间与其余代码并行存在，因为它只会使重构名称空间花费两倍的时间。 为了简化解决方案资源管理器中的简洁性，我通常将测试项目命名为Project-Tests，并将命名空间使用Company.Namespace.Tests。 |
