.NET assemblies spanning multiple files and unit testing

Question

Can anyone point me to some information on .NET assemblies spanning multiple files?

I've found this remark on MSDN (here):

Although it's technically possible to create assemblies that span multiple files, you're not likely to use this technology in most situations.

I'm asking because I have the business logic and the unit tests for it in separate projects, and I'd like to test some internal classes (which are not accessible from the unit tests) - so I thought I'd try and merge the two into a single assembly.

Answer 1

Testing of internal classes should happen through testing your public methods.

Answer 2

You can friend two assemblies together. Then one can see the "internal" in the other. Still can't see private.

MSDN - http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

Answer 3

If you want to test internal methods, then InternalsVisibleTo is the attribute for you. In fact, testing internal classes/methods is virtually the only thing I've ever used it for.

(Basically you apply it to the production assembly, specifying the test assembly - the test assembly can then access internal members.)

Answer 4

I'd say decide between the 2 options below

• If the internal classes are really trivial and private to the parent assembly, skip the tests. The tests for the public classes that exercise these internal classes should cover them.
• If the internal class are sizable and really need their own tests. Split the responsibility of access control to another class. Make the internal classes public and write tests like usual. Make it a known team convention that the internal classes are not directly instantiated outside the parent assembly or rather use the other class as a single point of access to the 'internal classes'.

IMHO Only if you're really worried about not exposing the internal types + absolutely must test them, go for Option2. Option1 allows you to change the internal implementation/classes at any time without breaking any tests. Don't use obscure ways of splitting assemblies across multiple physical files for testing.