Should .Net test classes reside in a different project?

Question

The convention in Java is different - every "module" (equivalent to Java in IntelliJ) has a src and test directory. jUnit can thus run per project, and there's no need for a separate test project.

Answer 1

Yes - Test classes should go in their own test project.

Answer 2

Yes definitely, you do not want your production assemblies to contain test code (since it is not part of the product as such, but rather part of the development framework around it).

Answer 3

Yes - you're testing external references. You can be in the same solution, although even that is considered a bit of a shortcut by some purists.

Answer 4

As you've probably picked up on, the usual .NET convention is to have the test code in a separate assembly (broadly speaking, in Visual Studio, each Project yields a distinct assembly).

Why is it so?

• Gives deployment choices
  Many (including I) believe that you shouldn't be deploying tests to production.
• Limits test access
  Helps to ensure that tests are working against the public interface of the code under test, which increases the need to get your API design right (though sometimes this is a limitation - see Question 261177 for example.)
• Helps keep each test small
  I used to roll my tests into the same project, but found there was a temptation to reuse too much code, resulting in unit tests that did too much, and were much too brittle.

For what it's worth, I keep my tests in separate projects, though in the same solution, using the [InternalsVisibleTo] attribute as necessary. I name each test as .Tests.dll, and then use a wildcard in a NAnt script to find all the tests to run.

Answer 5

Note: part of the reason you keep tests in the same package in Java is because your tests have to reside in the same package to test package-visible methods. InternalsVisibleTo bypasses this restriction in .Net.