Unit Testing in .NET with NUnit
January 24th, 2005
I recently reorganized a set of projects in Visual Studio by creating a separate project to hold the unit tests. I personally find it is best to place the test classes in a separate area than the rest of the codebase so that I can easily produce assemblies which do not include the test code.
And when I create these unit tests I place them in a namespace starting with UnitTests which has consequences, which are partially intended. I feel that I should only unit test public interfaces because private or otherwise internal methods are part of the encapsulated implementation. Calling these hidden methods directly breaks encapsulation so I do not do it.
As far as keeping unit test classes out of the assemblies my organizational style works but I recently found that you can simply use directives to strip out code using a compile-time directive. I read about it in the Testing Internal Methods blog entry. It is something worth considering. I feel I will still separate my unit tests with a separate project but now I think I could adjust logging with these compile-time directives to give me more detail during development and less detail in production.
As an unexpected consequence of pulling the unit tests out to a separate project I had to set a few web application projects as dependencies of the unit tests project. When I did that I found that a couple projects which were supposed be using the same version of a third-party component were actually on a different release. So I was able to correct it. Having all projects listed as a dependency of the unit tests project means I have to compile everything to build the unit tests assembly. It also allows me to point NUnit at the single output assembly to access all unit tests across all projects in the solution. I also have one place to configure database and other settings needed in the unit tests.
January 24th, 2005 at 2:37 pm
I find using the separate projects easier than using directives. When maintaining code I hate seeing all different kinds of directives in the main code. I can understand having them if you are working on a bug, but please people get rid of them before the code goes live.
January 24th, 2005 at 2:44 pm
I agree. I have read C and C++ code with these directives and it is just insane. But in C the purpose is to allow them to place cross-platform support into the codebase, like including a different header or calling a different threading implementation. It is not as important for languages like C# and Java which has the standardized runtime.
Also with Java and C# you can use Ant and Nant scripts which will allow you to automatically strip out some lines of code or ignore some files during the compile process so there is not need for those directives.
January 25th, 2005 at 3:32 am
.NET 2.0 introduces partial classes in C#. These let you easily have tests within a class (so you can test private stuff in the class as well as the public interface - I know that's frowned on by some and smiled on by others, but for me it helps get the job done) while still keeping the test code away from the "real" code. Works well for me.
For example, we have MyClass.cs containing the class code, and an accompanying MyClass.Tests.cs file which has the unit tests. Everything in that file is enclosed in a #if TEST condition.