TDD Naming styles
Project names
Just recently I have been discussing a different approach to our naming convention for our test projects at work. A commonly accepted way is to append the project names with “Tests” or “Specifications” suffix. Like the following example shows us three different projects:1 namespace Fohjin.Core { }
2 namespace Fohjin.Core.Tests { }
3 namespace Fohjin.Core.Specification { }
But I don’t really like how the namespaces look like when you are appending the Tests or Specifications suffixes to the base namespaces. Take a look at the following namespaces in the three different projects:
1 namespace Fohjin.Core { }
2 namespace Fohjin.Core.Controllers { }
3 namespace Fohjin.Core.Persistence { }
4
5 namespace Fohjin.Core.Tests { }
6 namespace Fohjin.Core.Tests.Controllers { }
7 namespace Fohjin.Core.Tests.Persistence { }
8
9 namespace Fohjin.Core.Specification { }
10 namespace Fohjin.Core.Specification.Controllers { }
11 namespace Fohjin.Core.Specification.Persistence { }
I would like to suggest an other approach, instead of appending a suffix I would like to prefix the project names with “Tests” or “Specifications”. Because this will result in the following namespaces:
1 namespace Fohjin.Core { }
2 namespace Fohjin.Core.Controllers { }
3 namespace Fohjin.Core.Persistence { }
4
5 namespace Tests.Fohjin.Core { }
6 namespace Tests.Fohjin.Core.Controllers { }
7 namespace Tests.Fohjin.Core.Persistence { }
8
9 namespace Specification.Fohjin.Core { }
10 namespace Specification.Fohjin.Core.Controllers { }
11 namespace Specification.Fohjin.Core.Persistence { }
As you can see the namespaces in the Test and Specification projects are not interrupted with the words Tests or Specifications anymore. I know it is not a huge deal but I like how this reads just a little bit better. Also if you have multiple test or specification projects they are nicely grouped together, something I used to do using solution folders. Well actually still do that :)
TDD class names
Now if we have specific projects for our tests do we still need to append our classes with “Test”? I mean it is obvious that anything in these projects are related to testing. So I would say that that is not needed anymore.So what do you say?
It should have been suffix.
Tuna Toksoz, Friday, May 22, 2009 at 7:20 PM
Hi Tuna,
I am playing with the idea with respect to class names, in a test project most of your classes will be test classes so why not specify the exceptions from that. And by using the identical project structure as the actual code it will still be easy to find the tests. So far I have only tried with the suffix but in my next project I'll try without I am also going to really drive it using MSpec but that is besides the point :)
-Mark
Mark Nijhof, Friday, May 22, 2009 at 7:31 PM
Locating the test is again easy with following the same folder structure as the units. (The resharper should have this feature, clicking on an icon near class should take me to test and vice versa). Specifying exceptions from the usual one might be okay but what happens if you have dummy entities, for example? UserEntity.cs PostEntity.cs ? I prefer User and Post with MembershipFixture.cs
The namespace idea is cool, even though I probably go with traditional .Tests approach. May try the idea in some new projects, though.
Tuna Toksoz, Friday, May 22, 2009 at 7:42 PM
I've also had problems naming my test namespaces - it never felt quite right - and your suggestion seems obvious. Wish I though of it myself :)
Torbjørn Marø, Friday, May 22, 2009 at 10:38 PM
Regarding the Test.-prefix for namespaces I disagree, even though for rather minor reasons. One is that namespaces form a hierarchy in which lower level namespaces automatically access all higher level namespaces.
That is, if you have a namespace MyCompany,Domain and you put your tests into MyCompany.Domain.Tests you can access all classes (especially the SUTs) from MyComany.Domain without a using directive. If you put your tests into Tests.MyComany.Domain you'll have to use a using directive. It's not that much of a problem, but it adds clutter and works against the inherent structure of namespaces.
That said, I structure my unit tests like that:
SUT Project: Company.dll
namespace Company.Domain
- class Entity
- class AnotherEntity
- ...
Unit tests project: Company.Tests.dll
namespace Company.Domain.EntitySpecs
- class when_chaging_some_property (a single test case/scenario)
- class when_object_is_in_valid_state
- ...
namespace Company.Domain.AnotherEntitySpecs
- class when_some_other_case
- class when_even_another_scenario
- ...
I keep the namespace hierarchy intact and group tests per Unit in their own namespace.
Regards,
Andre
Andre Loker, Saturday, May 23, 2009 at 8:21 AM
I prefer to create test classes with sufix Test: because I very often have many files opened in Visual Studio.
With 'Test' sufix (which is also in filename) it's easy to find test classes.
Tomasz M, Wednesday, May 27, 2009 at 11:03 PM
Recent blog posts
- Follow me @ Elegant Code
- CQRS à la Greg Young
- CQRS à la Greg Young example code
- My Kindle DX
- My book: Are You Better Than Yesterday?
- Running with Scissors
- Applying Domain-Driven Design and Patterns
- Hey Developer, YAGNI I tell you
- Hey Developer, the product you create is your code
- NDC videos are published
Not all the classes are tests, some may be helpers. Locating tests is easy with Test prefix.
Imho
Tuna Toksoz, Friday, May 22, 2009 at 7:19 PM