I too prefer "Tests" prefixing the actual name of the assembly so that its easy to see all of my unit test assemblies listed alphabetically together when I mass-select them to pull into NUNit or whatever test harness you are using.
So if Website were the name of my solution (and assemblies), I suggest -
Tests.Website.dll to go along with the actual code assembly Website.Dll
I don't care about any sub-namespaces like Company.Website.Controls, all of the tests go into the same namespace: Company.Website.Tests. You don't want your test namespaces to HAVE to be in parrallel with the rest of your code because it just makes refactoring namespaces take twice as long.
This way the tests are close to the code that is being tested, without having to toggle back and forth between projects or hunt down references to ensure there is a test covering a particular method. We also don't have to maintain two separate, but identical, hierarchies.
We can also test distinct parts of the code as we enhance and develop.
Seems a little weird at first, but over the long term it has worked really well for us.
I'm a big fan of structuring the test namespace like this:
Company.Tests.Website.xxx
Company.Tests.Website.Controls
Like you, I think of the tests as a parallel namespace structure to the main code and this provides you with that. It also has the advantage that, since the namespace still starts with your company name you shouldn't have any naming collisions with 3rd party libraries
With MVC starting to become a reality in the .net web development world, I would start thinking along those lines. Remember that M, V and C are distinct components, so:
Company.Namespace.Website
Company.Namespace.Website.Core
Company.Namspance.Website.Core.Tests
Company.Namespace.Website.Model
Company.Namespace.Website.Model.Tests
Website is your lightweight view. Core contains controllers, helpers, the view interfaces, etc. Core.Tests are your tests for said Core. Model is for your data model. The cool thing here is that your model tests can automate your database specific tests.
This may be overkill for some people, but I find that it allows me to separate concerns fairly easily.
发布评论
评论（10）
我更喜欢 Company.Website.Spec，并且通常每个解决方案都有一个测试项目
I prefer Company.Website.Spec and usually have one test project per solution
我也更喜欢在程序集的实际名称前加上“Tests”前缀，这样当我批量选择它们以将其拉入 NUNit 或您正在使用的任何测试工具时，可以很容易地看到按字母顺序列出的所有单元测试程序集。
因此，如果 Website 是我的解决方案（和程序集）的名称，我建议 -
Tests.Website.dll 与实际代码程序集 Website.Dll 一起使用
I too prefer "Tests" prefixing the actual name of the assembly so that its easy to see all of my unit test assemblies listed alphabetically together when I mass-select them to pull into NUNit or whatever test harness you are using.
So if Website were the name of my solution (and assemblies), I suggest -
Tests.Website.dll to go along with the actual code assembly Website.Dll
为了在解决方案资源管理器中简洁起见，我通常将测试项目命名为 Project-Tests，并使用 Company.Namespace.Tests 作为命名空间。
I usually name test projects Project-Tests for brevity in Solution Explorer, and I use Company.Namespace.Tests for namespaces.
我更喜欢使用：
Company.Website.Tests
我不关心任何子命名空间，例如 Company.Website.Controls，所有测试都进入同一命名空间：Company.Website.Tests。 您不希望测试命名空间必须与其余代码并行，因为这只会使重构命名空间花费两倍的时间。
I prefer to go with:
Company.Website.Tests
I don't care about any sub-namespaces like Company.Website.Controls, all of the tests go into the same namespace: Company.Website.Tests. You don't want your test namespaces to HAVE to be in parrallel with the rest of your code because it just makes refactoring namespaces take twice as long.
我们遵循嵌入式方法：
这样测试就接近正在测试的代码，而不必在项目之间来回切换或寻找引用以确保有一个涵盖特定方法的测试。 我们也不必维护两个独立但相同的层次结构。
我们还可以在增强和开发时测试代码的不同部分。
乍一看有点奇怪，但从长远来看，它对我们来说非常有效。
We follow an embedded approach:
This way the tests are close to the code that is being tested, without having to toggle back and forth between projects or hunt down references to ensure there is a test covering a particular method. We also don't have to maintain two separate, but identical, hierarchies.
We can also test distinct parts of the code as we enhance and develop.
Seems a little weird at first, but over the long term it has worked really well for us.
我非常喜欢构建这样的测试命名空间：
Company.Tests.Website.xxx
Company.Tests.Website.Controls
和你一样，我也想到了测试作为主代码的并行命名空间结构，这为您提供了这一点。 它还具有的优点是，由于命名空间仍然以您的公司名称开头，因此您不应该与第 3 方库发生任何命名冲突
I'm a big fan of structuring the test namespace like this:
Company.Tests.Website.xxx
Company.Tests.Website.Controls
Like you, I think of the tests as a parallel namespace structure to the main code and this provides you with that. It also has the advantage that, since the namespace still starts with your company name you shouldn't have any naming collisions with 3rd party libraries
我个人会选择
Company.Tests.Website
这样你就有了一个通用的测试命名空间和其中的项目，遵循与实际项目相同的结构。
I personally would go with
Company.Tests.Website
That way you have a common tests namespace and projects inside it, following the same structure as the actual project.
我实际上有一个备用平行根。
Tests.Company.Website
当您有新的子命名空间时，它可以很好地消除歧义。
I actually have an alternate parallel root.
Tests.Company.Website
It works nicely for disambiguating things when you have new sub namespaces.
我会选择
简短的原因和答案很简单，测试和项目在代码中链接，因此它应该共享命名空间。
如果您想要拆分代码并在解决方案中进行测试，无论如何您都可以选择。 设置解决方案
-CodefolderCompany.Website
-TestsFolderCompany.Website.Tests
I will go with
The short reason and answer is simple, testing and project are linked in code, therefore it should share namespace.
If you want splitting of code and testing in a solution you have that option anyway. e.g. you can set up a solution with
-Code Folder
-Tests Folder
随着 MVC 开始在 .net Web 开发世界中成为现实，我将开始沿着这些思路思考。 请记住，M、V 和 C 是不同的组件，因此：
网站是您的轻量级视图。
Core 包含控制器、帮助器、视图接口等。Core.Tests 是对所述 Core 的测试。
模型适用于您的数据模型。 这里最酷的事情是您的模型测试可以自动化数据库特定的测试。
对于某些人来说这可能有点过分了，但我发现它可以让我很容易地分离关注点。
With MVC starting to become a reality in the .net web development world, I would start thinking along those lines. Remember that M, V and C are distinct components, so:
Website is your lightweight view.
Core contains controllers, helpers, the view interfaces, etc. Core.Tests are your tests for said Core.
Model is for your data model. The cool thing here is that your model tests can automate your database specific tests.
This may be overkill for some people, but I find that it allows me to separate concerns fairly easily.