Just wanted to let y’all know that Nunit 2.0 rocks !  As if you didn’t know that already…

The NUnitAddIn is also very cool, although it is far from stable. I find myself stopping the service and restarting VS.NET every few minutes when working with it, but it is definitely worth the added trouble.

Can anyone recommend a good unit testing standards set? Currently for each of my namespaces I am adding a “.UnitTests” child namespace, and placing in there a test class for each of my classes (more or less) which has the same name with a “_UnitTest” suffix.  So it would look like this:

{} MyNamespace
         +  MyFirstClass
         +  MySecondClass

{} MyNamespace.UnitTests
         +  MyFirstClass_UnitTests
         +  MySecondClass_UnitTests

This is working fairly well for me so far, but it doubles the number of namespaces & classes in the project which is a bit annoying to work with. Has anyone actually imbedded their unit tests inside their classes? If so, is there any way to filter out those methods when compiling for release?

I’ll check it out and post my results….


Comments (4)

  1. Anonymous says:

    I always make my unit tests in a seperate project with a seperate namespace, so the tests can be included/excluded with ease, depending on build configuration and such.

  2. Anonymous says:

    I have been creating my unit test classes as nested classes. I like this for two reasons. First, it cuts down on the number of classes appear to be in the namespace. Second, a nested class has access to private instance variables of an instance of its containing class. This little trick can make writing unit tests that need to manipulate a class’ internals(for whatever reason) much easier to write.

    As far as making the unit test "disappear" from my compile when I am not testing, I normally wrap the unit test class within a #if DEBUG preprocessor conditional. This way, the unit tests are not included in my release code.

  3. Anonymous says:

    I was going to say the same as Philip. Nested classes and #if DEBUG is the way to go. You can keep your code uncluttered by wrapping the tests in a #region.

    I’m sorry you’ve been having stability issues with NUnitAddin. I’m particularly surprised you’ve been needing to restart Visual Studio. Tests are run in a separate process to avoid this kind of thing. If you can find a reproducable way of breaking it I’ll do my best to fix it. Has the problem been when using the ‘Debug Tests’ feature?

    Thanks, Jamie.

  4. Anonymous says:

    Creating unit test classes as nested classes : CSharpener’s Blog