We put all of our unit tests in their own projects. We find that we have to make certain classes public instead of internal just for the unit tests. Is there anyway to avoid having to do this. What are the memory implication by making classes public instead of sealed?
Classes can be both public AND sealed.
But, don't do that.
You can create a tool to reflect over internal classes, and emit a new class that accesses everything via reflection. MSTest does that.
Edit: I mean, if you don't want to include -any- testing stuff in your original assembly; this also works if the members are private.
If it is an internal class then it must not be getting used in isolation. Therefore you shouldn't really be testing it apart from testing some other class that makes use of that object internally.
Just as you shouldn't test private members of a class, you shouldn't be testing internal classes of a DLL. Those classes are implementation details of some publicly accessible class, and therefore should be well exercised through other unit tests.
The idea is that you only want to test the behavior of a class because if you test internal implementation details then your tests will be brittle. You should be able to change the implementation details of any class without breaking all your tests.
If you find that you really need to test that class, then you might want to reexamine why that class is internal in the first place.
If you're using .NET, the InternalsVisibleTo assembly attribute allows you to create "friend" assemblies. These are specific strongly named assemblies that are allowed to access internal classes and members of the other assembly.
Note, this should be used with discretion as it tightly couples the involved assemblies. A common use for InternalsVisibleTo is for unit testing projects. It's probably not a good choice for use in your actual application assemblies, for the reason stated above.
Appears to be a duplicate of How do I allow assembly (unit testing one) to access internal properties of another assembly ?