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?

Answer 3

I've worked on a large project (5 million lines of code, ~160,000 unit tests) that used to put the test class at the bottom of each file, in a separate namespace, wrapped in an #if DEBUG.

The references to NUnit existed in production, but the test code wasn't included in the release build so it didn't make the production DLLs any larger.

The benefit was the test code was right there alongside the production code, so it was never hard to find the tests. It was also clear which tests belonged to which classes, and there was no need to try to mimic a namespace hierarchy in a tests folder, which is always a hassle if the namespaces or class names change.

It worked quite successfully for the project, but opinions and mileage may vary these days :) The place I currently work for has a structure very similar to the one Sam Holder describes.