10

Background

I am working on a project with C# .NET, and I've just added a new unit test project to my solution in Visual Studio. The way that I always have been doing this is:

  1. Create a new unit test project.
  2. Have that project include a reference to the project under test.
  3. Just include (using) the project.

I guess the other way you could do it would be...

  1. Create a new unit test project.
  2. Have that project include a reference to the project under test.
  3. Make the unit test project share a namespace with the project under test.

Question

Is there an accepted way of doing this for projects in the .NET world, or, is this just an opinion and there is nothing more to it?

Improve this question
17
  • 3
    Using the same namespace just seems a way to end up with namespace conflicts. And you'd still need a reference to the assembly containing the code under test.
    – David Arno
    May 12, 2016 at 14:52
  • 2
    I concur with David. Unless you're careful to explicitly name your test methods something different to the method under test, you risk there being naming conflicts. I just don't see how sharing a namespace brings anything to the party.
    – Robbie Dee
    May 12, 2016 at 15:43
  • 2
    If they're written properly, tests should never conflict, since the method names will be something like MethodName_StateUnderTest_ExpectedBehavior(), and I'm sure you could find suitable non-conflicting names for the test classes. The real question is: do you really want those types showing up in your intellisense?
    – Robert Harvey
    May 12, 2016 at 16:22
  • 1
    @DavidArno TDD is not applicable in every situation. If all my code does is go and read some electronic device and return a result (which is 99% of the time for EEs writing code)... All I care about is whether or not I get the right value, at that point it doesn't matter whether I write the test before or after.
    – Snoop
    May 12, 2016 at 16:36
  • 1
    @StevieV, my apologies, that wasn't supposed to be a serious comment (thus the smiley face), but I guess it didn't come across like that.
    – David Arno
    May 12, 2016 at 16:45

2 Answers 2

Reset to default
14

Your unit tests are in a separate project and serve a separate function from your main code, so putting them into a separate namespace makes the most sense to me.

If you're considering putting them into the same namespace just to save the using line, then don't. Less code is good, clearer code is better.

Improve this answer
4
  • 2
    And you don't want to release/distribute/deploy unit tests.
    – radarbob
    May 14, 2016 at 19:32
  • 1
    Putting tests in a separate namespace ensures (in some languages) that you're seeing the API as a third party consumer would, i.e., not accessing members that are only accessible to classes in the same namespace. Conveniently, your tests will silence any spurious warnings about your public API members being unreferenced or unnecessarily exposed.
    – StackOverthrow
    Mar 13, 2018 at 21:13
  • @TKK The question is about C# and in C#, namespaces don't work like that.
    – svick
    Mar 13, 2018 at 22:48
  • @svick: yes, and C# does not force you to give each assembly its own namespace. However, it is a useful convention, especially in larger projects, and I would not handle a unit test assembly differently than any other assembly on this.
    – Doc Brown
    Apr 25, 2018 at 16:02
4

I've used unit tests project with the same namespace as the real project (by manually removing the Tests suffix on the test project namespace) for a few years with zero issues.

I think it leads to more straightforward code so I usually suggest going that approach. Some of the drawbacks, like potential namespace conflicts, just shouldn't happen when dealing with a unit test project since you are already following some test conventions for that, like suffixing all test classes with Tests. Additionally, to me it sounds quite intuitive to have the classes and the test classes in the same namespace.

Some people will think it's strange, but this really shouldn't be the case, as lots of framework assemblies also use this strategy of having multiple DLLs that have classes in the same namespaces: it is not supposed to be a surprising thing or a bad practice in and of itself.

I do think this one is more on personal taste though, so it's not really "answerable" per-se. Having said that, "my vote", as per reasoning above, is to try it for yourself at first, and if you like the approach, go for it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.