在.NET(或者任何其他语言或者平台)中命名测试程序集的最佳约定是什么？

我主要区分的是这些选项(请提供其他选项！)：

• Company.Website-项目
• 公司网站测试

或者

• 公司网站
• Company.WebsiteTests

第一种解决方案的问题在于，看起来.Tests是站点的子命名空间，而在我看来它们确实更像是并行的。当一个新的子命名空间(例如Company.Website.Controls)开始发挥作用时，会发生什么情况？例如，我应该将该命名空间的测试放在哪里？

甚至应该是：Tests.Company.Website和Tests.Company.Website.Controls，依此类推。

解决方案

回答

我个人会去

公司。测试网站

这样，我们将拥有一个通用的测试名称空间和其中的项目，并遵循与实际项目相同的结构。

回答

我实际上有一个备用并行根。

Tests.Company.Web站点

当我们拥有新的子命名空间时，它可以很好地消除歧义。

回答

为了简化解决方案资源管理器中的简洁性，我通常将测试项目命名为Project-Tests，并将命名空间使用Company.Namespace.Tests。

回答

我非常喜欢这样构造测试名称空间：

Company.Tests.Website.xxx

Company.Tests.Website.Controls

像我们一样，我将测试视为与主代码的并行名称空间结构，这为我们提供了这一点。它还具有的优点是，由于名称空间仍然以公司名称开头，因此我们不应与第三方库发生任何命名冲突

回答

我更喜欢：

公司网站测试

我不在乎像Company.Website.Controls这样的子命名空间，所有测试都进入同一个命名空间：Company.Website.Tests。我们不希望测试名称空间与其余代码并存，因为这只会使重构名称空间花费两倍的时间。

回答

我更喜欢Company.Website.Spec，每个解决方案通常有一个测试项目

回答

我们遵循一种嵌入式方法：

Company.Namespace.Test
Company.Namespace.Data.Test

这样，测试就可以与正在测试的代码接近，而不必在项目之间来回切换或者查找引用以确保存在涵盖特定方法的测试。我们也不必维护两个单独的但相同的层次结构。

当我们增强和开发时，我们还可以测试代码的不同部分。

乍一看似乎有些不可思议，但从长期来看，它对我们来说确实很好。

回答

我会一起去

* Company.Website - the project
* Company.Website.Tests

简短的原因和答案很简单，测试和项目通过代码链接在一起，因此应该共享名称空间。

如果我们想拆分代码并在解决方案中进行测试，则仍然可以选择该选项。例如我们可以使用以下方法设置解决方案

-代码文件夹

• 公司网站

-测试文件夹

• 公司网站测试

回答

我也更喜欢以" Tests"作为程序集实际名称的前缀，这样当我批量选择它们放入NUNit或者使用的任何测试工具中时，可以轻松地按字母顺序列出所有我的单元测试程序集。

因此，如果网站是我的解决方案(和程序集)的名称，我建议-

Tests.Website.dll与实际的代码汇编Website.Dll一起使用

回答

随着MVC开始在.net Web开发世界中成为现实，我将沿着这些思路思考。请记住，M，V和C是不同的组件，因此：

• Company.Namespace.Website
• Company.Namespace.Website.Core
• Company.Namspance.Website.Core.Tests
• Company.Namespace.Website.Model
• Company.Namespace.Website.Model.Tests

网站是轻量级视图。
Core包含控制器，助手，视图界面等。Core.Tests是我们对所说Core的测试。
模型适用于数据模型。这里很酷的事情是，模型测试可以自动化数据库特定的测试。

对于某些人来说，这可能是过大的杀伤力，但我发现它使我可以很容易地将关注点分开。