.NET Testing Naming Conventions

Question

What are the best conventions of naming testing-assemblies in .NET (or any other language or platform)?

What I'm mainly split between are these options (please provide others!):

• Company.Website - the project
• Company.Website.Tests

or

• Company.Website
• Company.WebsiteTests

The problem with the first solution is that it looks like .Tests are a sub-namespace to the site, while they really are more parallel in my mind. What happens when a new sub-namespace comes into play, like Company.Website.Controls, where should I put the tests for that namespace, for instance?

Maybe it should even be: Tests.Company.Website and Tests.Company.Website.Controls, and so on.

Answer 1

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.

Answer 2

I actually have an alternate parallel root.

Tests.Company.Website

It works nicely for disambiguating things when you have new sub namespaces.

Answer 3

I usually name test projects Project-Tests for brevity in Solution Explorer, and I use Company.Namespace.Tests for namespaces.

Answer 4

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

Answer 5

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.

Answer 6

I prefer Company.Website.Spec and usually have one test project per solution

Answer 7

We follow an embedded approach:

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

This way the tests are close to the code that is being tested, without have to toggle back and forth between project 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 heirarchies.

We can also Test distinct parts of the code as we enhance and develop.

Seems a little weird at first, but over the long tern it has worked really well for us.

Answer 8

I will go with

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

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

• Company.Website

-Tests Folder

• Company.Website.Tests

Answer 9

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

Answer 10

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.