Using "friend"-declarations for unit testing. Bad idea?

Question

[Of course, the question is not restricted to a specific "friend" implementation, feel free though to point out implementation specifics if relevant]

Reading through the unanswered questions, I stumbled upon the InternalsVisibleTo attribute:

Specifies that types that are ordinarily visible only within the current assembly are visible to another assembly.

The C# Programming Guide on MSDN has a section Friend Assemblies describing how to use the attribute to allow the use of internal methods and types to another assembly.

I'm wondering whether it would be a Good Idea to use this to create a "hidden" interface for instrumenting a library for use by the unit testing assembly. It seems to increase coupling massively in both directions (testing code in the production assembly, intimate internal knowledge about the production assembly in testing code), but on the other hand it might help in creating fine-grained tests without cluttering the public interface.

What is your experience with using friend declarations when testing? Was it your Silver Bullet, or did it start the Death March?

Answer 1

It's the only use I've ever personally applied to InternalsVisibleTo - and it's been very, very handy indeed.

I don't view unit tests as black box testing - they're already coupled to the implementation to some extent. Being able to test internal types and methods allows a much tighter focus (smaller units).

Answer 2

I've made extensive use of this technique - it means that my unit tests can test aspects of the code library that aren't visible to normal consumers.

While using [InternalsVisibleTo] does increase coupling, I believe the (minor) increase is well worth the gains.

My unit tests are already tightly coupled to the code under test - though I try to write tests that assure specific outcomes, not specific implementations, by accessing things not visible to regular consumers, I do somewhat constrain the implementation.

Going the other way, the coupling is minimal - in having the [InternalsVisibleTo] attribute on the code assembly, and in marking some things as internal instead of private (or protected internal instead of protected).

(Note that I'm ignoring here any design changes that are provoked by the use of Unit Testing, which is a whole other discussion.)

The [InternalsVisibleTo] attribute requires strong naming your assemblies. If you're not doing this already, you may find this a bit burdensome as a strongly named assembly may only depend on other strongly named assemblies, which may end up with you needing to alter several assemblies.

Getting the attribute right can be a bit fiddly, as it needs to include the public key of your test assembly. IDesign have a useful Friend Assembly tool that creates the attribute on your clipboard, ready for pasting. Recommended.

Answer 3

I hate to be a "me too", but I have also found this a useful trade-off for unit testing (but have never found another legitimate use for it).

Answer 4

I think using InternalsVisibleToAttribute to enable unit testing is perfectly reasonable. My "unit" in "unit testing" is a class, and that includes internal classes, so I want to test them. I don't want to unit test private methods, though.

I don't think creating a special, private interface just for tests is a good idea. One of the values of unit testing is that it gives you a chance to think about the interface to your class from the point of view of a consumer of that class; providing a back door takes that benefit away.

My preference, however, is to put my unit tests in the same assembly as my production code. It doesn't usually affect my customer, but it does simplify things for me, so I do it. When I do, it makes the InternalsVisibleTo question go away.

Answer 5

In fact, Unit Testing is the only use that I've been able to bring myself to use the InternalsVisibleToAttribute for. With this you can implement a large portion of your 'private' methods as internal instead to expose them to the unit testing framework for more invasive testing of class-internal invariants.

I've had great success with this technique. If nothing else it helps you approach that mythical 100% code coverage goal by letting you invoke private methods in situations that are otherwise inaccessible.

Answer 6

I think another legitimate use case comes in when you have used separate assemblies when bringing together legacy C++ code with newer C# code.

We've taken the C++ assemblies, converted them to C++/CLI, and then implement newer code in C#. When we do this, we would still use "internal" for the classes/methods in C# that aren't really public, and then make these available to the legacy code as friend assemblies.