.NET 测试命名约定 [关闭]

题

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

我主要分为以下这些选项（请提供其他选项！）：

或者

第一个解决方案的问题在于，它看起来像 .Tests 是站点的子命名空间，而在我看来它们确实更加并行。当新的子命名空间发挥作用时会发生什么，例如 公司.网站.控件, ，例如，我应该在哪里对该命名空间进行测试？

也许它甚至应该是： 测试.公司.网站 和 测试.公司.网站.控件, ，等等。

解决方案

我会和

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

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

如果您想要拆分代码并在解决方案中进行测试，无论如何您都可以选择。例如你可以设置一个解决方案

-代码文件夹

-测试文件夹

其他提示

我个人会选择

公司.测试.网站

这样，您就有了一个通用的测试命名空间和其中的项目，遵循与实际项目相同的结构。

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

测试.公司.网站

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

我非常喜欢像这样构建测试命名空间：

公司.测试.网站.xxx

公司.测试.网站.控件

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

我也更喜欢在程序集的实际名称前加上“Tests”前缀，这样当我批量选择它们以将其拉入 NUNit 或您正在使用的任何测试工具时，可以很容易地看到按字母顺序列出的所有单元测试程序集。

因此，如果 Website 是我的解决方案（和程序集）的名称，我建议 -

测试.Website.dll 配合实际的代码汇编 网站.DLL

我们遵循嵌入式方法：

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

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

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

乍一看有点奇怪，但从长远来看，它对我们来说非常有效。

我通常命名测试项目 项目测试 为了简洁起见，我在解决方案资源管理器中使用 公司.命名空间.测试 对于命名空间。

我更喜欢搭配：

公司.网站.测试

我不关心任何子命名空间，如 Company.Website.Controls，所有测试都进入同一个命名空间：公司.网站.测试。您不希望测试命名空间必须与其余代码并行，因为这只会使重构命名空间花费两倍的时间。

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

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

网站是您的轻量级视图。核心包含控制器、助手、视图接口等。Core.Tests 是对所述核心的测试。模型适用于您的数据模型。这里最酷的事情是您的模型测试可以自动化数据库特定的测试。

对于某些人来说这可能有点过分了，但我发现它可以让我很容易地分离关注点。

许可以下： CC-BY-SA 和归因