Separating out unit tests

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 (4)

  1. Hi,

    When I first heard about the InternalsVisibleTo attribute I thought it was a great solution for the ‘how do you test internal types’ problem. I have since started to grow a little concerned. Going test first is a great way to think about how your API should look from the outside. Unfortunately this all breaks down as soon as you add an InternalsVisibleTo attribute. Suddenly the test writer can do things an ordinary consumer of the API wouldn’t be able to do. You have lost your objective view from outside the assembly and it isn’t at all obvious when you’re using your target’s internal types.

    I think this issue is solvable by making the interaction more explicit. If there was a complimentary attribute on the client side it would be more obvious what was going on. For example…

    [Test, InternalsVisible(typeof(TargetType))]

    void TestInternalMethods()


    // Test internal methods of the TargetType


    I believe this attribute is going to be used an awful lot and without this kind of check it has the potential to cause a lot of damage.

    Do you know who’s responsibility this feature comes under? I would like to get in touch to express my concerns.

    Thanks, Jamie.

  2. Kris says:

    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?



  3. jaybaz [MS] says:

    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.

  4. jaybaz [MS] says:


    Jason Anderson is on the team creating the unit test tools in Visual Studio.

    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: