Separating out unit tests

re: Separating out unit tests

Jamie Cansdale — Thu, 09 Sep 2004 22:24:00 GMT

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.

re: Separating out unit tests

Kris — Fri, 10 Sep 2004 00:07:00 GMT

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

re: Separating out unit tests

jaybaz [MS] — Fri, 10 Sep 2004 02:17:00 GMT

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.

re: Separating out unit tests

jaybaz [MS] — Fri, 10 Sep 2004 02:22:00 GMT

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