Share via

Separating out unit tests

  • Article

This question came up on a customer chat today. It’s probably interesting to a wider audience, so I’m posting it here.

I'm currently doing TDD with NUnit. With the upcoming testing tools in Whidbey, how do you see the separation of tests from production code taking place? I'm curious about how best to develop tests and then not deploy them.

Any of the techniques for test separation that work in NUnit will continue to work with Burton Unit Testing.

  • You can put the tests under #if, and toggle the flag for release builds.

  • You can put the tests in a separate netmodule that you either alink in or don't. (New features in Whidbey make doing this easier, too.)

  • You can leave them in the assembly and ship them to customers, if that suits you.

You also have some 2 new options:

  • Put the tests in a separate "friend" assembly, using the System.InternalsVisibleTo attribute.

  • Use the new Whidbey feature that generates reflection-based wrappers for your classes. This allows you to "violate" accessbility settings within your unit tests.

Overall, the behavior of the unit testing in Burton and NUnit are very similar. If you're comfortable with NUnit, it should be very easy for you to make the transition.

Comments

  • Anonymous
    September 09, 2004
    The comment has been removed
  • Anonymous
    September 09, 2004
    Hi, it seems like the most obvious current option is omitted, which is leaving test code in a separate assembly. Reflection is an option at that point for calling internal members, however; if a class can't be adequately tested via its public interface, it seems like there's a likely need to refactor since that public interface might be solving more than it should. What are your thoughts?

    Thanks,

    Kris
  • Anonymous
    September 09, 2004
    Kris & Jamie,

    I think that part of the conflict here is that the principle of "see your API from the consumers viewpoint" is difficult when the consumer has more access to the type than the test.

    For example, a 'private' nested class is worth testing, but difficult to reach with unit tests. Similarly, an 'internal' class in one assembly is difficult to test from tests in another assembly.

    To add to the confusion, note that there are different "consumer viewpoints". The consumer of a 'private' nested class is the outer class. The consumer of a 'public' type of a library vendor is your paying customer. In both cases, writing tests from their point of view helps you design with the consumer in mind, but adhering to that principle means something quite different in practice in each case.
  • Anonymous
    September 09, 2004
    Jamie:

    Jason Anderson is on the team creating the unit test tools in Visual Studio. http://blogs.msdn.com/jason_anderson/

    The InternalsVisibleTo feature spans a number of teams, so there's not one person to engage in discussion.

    If you want to send feedback, instead of discuss, the best place is probably LadyBug: http://lab.msdn.microsoft.com/productfeedback