Working effectively with unit tests / Anyone tried the in-assembly approach?

Question

I'm trying to re-introduce unit testing into my team as our current coverage is very poor.

Our system is quite large 40+ projects/assemblies. We current use a project named [SystemName].Test.csproj were all the test code is dumped and organised to represent the namespaces using folders. This approach is not very scalable and makes it difficult to find tests.

I've been thinking about added a Tests folder to each project, this would put the unit tests "in the developers face" and make them easy to find. The downside is the Production release code would contain references to nunit, nmocks as well as the test code and test data.... Has anyone tried this approach?

How is everyone else working with unit tests on large projects? Having a Tests project per "real" project/assembly would introduce too many new projs.

Thanks in advance

Answer 1

I personally use the in-project approach. Since a single project is a software module on it's own (and thus can be shipped, or used in other projects), I think the best approach is to tie the tests to the single software module, so it automatically follows the tested code.

Answer 2

I think this is a bad idea for the reasons you stated, you end up having references in the production code to testing assemblies, plus the fact that all your tests get compiled into your production code, unless you do some magic to exclude it.

You don't say why the tests are hard to find. If they reflect the structure of the things they are testing they should no harder to find than the code they are testing.

you should have a CI server which runs all the tests all the time, so that even if the tests are not in the devs face they can't get way from the fact that they have broken the build easily.

We tend to go for the tests in their own project but that project is in a Tests (or Tests.Integration or wahatever the tests are for) subfolder of the assembly they are testing. That way the tests are obtained when the code for the project is checked out and you don't have the test projects folders polluting the directory structure at the project level. But you do end up with at least 1 test project for every assembly you have. I think this is ok, unless you have many small assemblies, but in that case do you really need to have the code for all of them in the ide all the time, or could you simply have the code for the assemblies you are working on locally and have the other assemblies just referenced by dll?